Resource management is crucial for scaling digital twin representations in service architectures. Proper resource cleanup ensures system stability during scaling up and down. Rigorous resource management prevents resource exhaustion and orphaned resources consuming capacity. The Substrates API’s approach to resource management ensures resources are acquired and released during scaling operations. This is important in environments with rapidly fluctuating circuit numbers. The framework’s approach allows developers to focus on modeling while the underlying resource lifecycle is handled automatically, enabling reliable scaling without resource degradation.

The following code snippet is typical of the code presented in this series. It demonstrates how to use the Substrates API in a simple “Hello World” manner. It follows a typical pattern: creating a Circuit and a Conduit, subscribing to the Conduit’s Source, composing a Pipe, emitting a value, and waiting for the Queue to be drained.

The code above lacked resource cleanup, as illustrated below. Notice that the resource ordering is reversed compared to the code sequencing above, which is common for nested resource constructs. For instance, a Subscription operates within the lifespan of a Conduit, while a Conduit operates within the lifespan of a Circuit.

The Substrates API introduces three abstractions to help with resource management and structuring of code: Resources, Scopes, and Closures. A Resource encapsulates anything that requires explicit Closure when no longer in use. A Scope establishes a bounded context for managing these resources, automatically handling cleanup when its context terminates. The Closure bridges these concepts, providing controlled access to Resources within a Scope while ensuring proper resource management. By combining these abstractions, developers can safely interact with Substrates Resources without the concern of resource leaks. Here is the code using such constructs.

Another nice aspect of the Substrates API design in the context of resource management diagnostics is that scopes can be named and nested, and because like Name and Subject the Scope interface extends the Extent interface which extends Iterable it is possible to iterate outwards from a current scope to enclosing scopes.

The following is printed when the above code is executed, in which an outer and nested inner scope are created.

In the next article in the series, we look at how our code can be executed safely as a Script and by a Circuit.