Partial State Deferral

How can services be designed to optimize resource consumption while still remaining stateful?

Problem Service capabilities may be required to store and manage large amounts of state data, resulting in increased memory consumption and reduced scalability.
Solution Even when services are required to remain stateful, a subset of their state data can be temporarily deferred.
Application Various state management deferral options exist, depending on the surrounding architecture.	Impacts Partial state management deferral can add to the design complexity and bind a service to the architecture.
Principles Service Statelessness	Architecture Inventory, Service

Table 6.16 – Profile summary for the Partial State Deferral pattern.

Problem

Even though reduced statefulness is advocated by the Service Statelessness design principle, when service capabilities are composed as part of larger activities there is often a firm need for the service to remain active and stateful while other parts of the activity are being completed.

When the service is required to hold larger amounts of state data, the state management requirements can result in a significant performance drain on the underlying implementation environment. This can be wasteful when only a subset of the data is actually required for the service to accommodate the activity.

In high concurrency scenarios environments, the actual availability of the service can be compromised where accumulated, wasted resources compound to exceed system thresholds.

Figure 6.72 – In concurrent usage scenarios, stateful services will require that multiple service instances be invoked, each with its own measure of state-related memory consumption requirements.

Solution

The service logic can be designed to defer a subset of its state information and management responsibilities to another part of the enterprise. This allows the service to remain stateful while consuming less system resources. The deferred state data can be retrieved when required.

Figure 6.73 – Applying this pattern results in the same amount of concurrent service instances but less overall state-related memory consumption.

Application

This design pattern is almost always applied for the deferral of large amounts of business state data, such as record sets or code lists. The general idea is for these bodies of data to be temporarily off-loaded. To accomplish this, an effective state delegation option is required. This may preclude the use of the State Repository pattern unless virtual databases can be utilized to make the writing and retrieval of data efficient and responsive.

The Partial State Deferral pattern can be effectively used in conjunction with the System Services pattern so that state data transmissions can occur efficiently without writing to disk. Any state deferral extension can be used in support of this pattern, as long as the performance hit of transferring state data does not introduce unreasonable lag time to the overall activity and the extension also does not undermine the performance gain sought by the pattern itself.

Services designed with this pattern can be further optimized to minimize lag time by retrieving deferred state data in advance. Service logic algorithms can be augmented so that when access to the deferred data is anticipated, it can be retrieved during a previous processing step and is then ready for access without delay.

Impacts

Most state management deferral options require that the service move and then later retrieve the state data from outside of its boundary. This can challenge the preference to keep the service as a self-contained part of an inventory and can also bind its implementation to the technology architecture. The resulting architectural dependency may result in governance challenges should standard state management extensions ever need to be changed.

Furthermore, the routines required to program service logic that carries out runtime state data deferral and retrieval adds overall design and development complexity and effort. Finally, if the aforementioned algorithm optimization is not possible, the retrieval of large amounts of business data as part of a sequential processing routine will introduce some extent of lag time.

Relationships

This specialized pattern has relationships with the two other state management-related patterns (State Repository and Stateful Services) and also provides a common feature used in orchestration environments, as per the Process Centralization pattern. The application of Canonical Resources can further affect how this pattern is applied (namely the type of state deferral extension that ends up being used).

In support of the Service Statelessness design principle, the partial deferral of state data increases service scalability and therefore also supports Capability Recomposition.

Figure 6.74 – The Partial State Deferral pattern has basic relationships with other patterns that support or benefit from state management delegation.

Case Study Example

Case study content is not available on this Web site.