Space-based / Cloud Architecture pattern

Usage:

This pattern is useful for applications that have variable and unpredictable concurrent user volumes by minimizing the factors that limit application scaling.

Scaling Problem :

Most web-based applications follow the same general request flow: a request from a browser hits the web server, then the application server, then finally the database server. while this pattern works great for a small set of users, bottlenecks start appearing as the user load increases.

• Scaling the web-server layer is easy to do but it's just moving the bottleneck down to the application server.
• Scaling application servers can be more complex and expensive but it also moves the bottleneck down to the database servers.
• Scaling database servers is more difficult and expensive to scale.

The database will be the final limiting factor in how many concurrent users can access the application.

Solution:

This pattern solves the problem by removing the central database, application data is kept in memory and replicated among all processing units, and asynchronously sends the data to the database, usually via messaging with a persistent queue.

Architecture components:

1 - The processing unit

Typically contains the application logic along with an in-memory data grid and optional persistent store for failover. it also contains a replication engine that is used by the virtualized middleware to replicate the data changes made by one processing unit to other active processing units.

2 - The virtualized middleware

Handles the infrastructure concerns that control data synchronization and request handling.

• Messing grid managing input request and session information, determining which active processing units are available to receive the request
• The data grid interacts with the data replication engine in each processing unit to manage the data replication between processing units when data updates occur.since the messaging grid can forward the request to any active processing unit, it's essential that each processing unit contains exactly the same data.
• The processing grid is an optional component to manage distributed requests (requests require coordination between multiple processing units).
• The Deployment manager manages the startup and shutdown of the processing units based on load conditions.

3 - Data Pumps

Is a way of sending the data to another processor which then updates the database.

data pumps are usually implemented using messaging.

4 - Data Writers

Accepts the data from pumps and updates the database accordingly.

5 - Data Readers

Read the data from the database and send it to the processing unit via a reverse data pump.

used in three cases:

• Crash all processing units
• Redeployment of all processing units
• Fetching archived data that doesn't exist in the cache.

Caching topology

while the replicated cache is the most common caching topology used in space-based architecture. distributed, or hybrid cache can be used also based on the amount of data or nature of the data (static, dynamic) and update rate.

In case of high data volume and and high update rate distributed cache can be used.

In case data is relatively static and low data volume replicated cache can be used.

To know more about caching topologyies and usage for each one check this article.

Consideration

The space-based architecture style is a complex and expensive pattern, it's a good choice for smaller web-based applications that have unpredictable high spikes in user requests like(sports ticketing systems, online auction systems, ...). These kinds of systems expect high spikes only when tickets go on sale or bidding on an item starts otherwise no user requests are expected.

It's not well suited for traditional large-scale relational database applications with large amounts of operational data.

Pattern analysis

Sources:

Fundamental of software architecture.