The space-based architecture is a highly scalable and highly elastic architecture style that is most suitable for highly concurrent applications with variable scale. The core concept of this architecture style is the use of multiple parallel processors that communicate through shared memory. Application data is stored in memory and replicated to all processing units. If one processing unit updates the data, the change is propagated to the database and the other active processing units. These changes are picked up by other processing units at start up. Since there is no centralized database that would have been a bottleneck to scalability, this architecture is free to scale dynamically based on the load of the system.
Architecture Components
The basic topology of the space-based architecture consists of five components:
- Processing Unit: contains and executes the application code
- Virtualized Middleware: manages and coordinates the processing units
- Data Pump: asynchronously sends updated data to the database
- Data Writer: performs the database updates from the data pumps
- Data Reader: delivers data from the database to the processing units
Processing Unit
Each processing unit contains all or some of the application logic, usually divided based on functional areas of the application. A processing unit can also contain a small, single-purpose service known as a microservice. Additionally, a processing unit also contains an in-memory data grid, which is a cache of the data in the database, as well as a data replication engine, which replicates the in-memory cache to other processing units.
Virtualized Middleware
The virtualized middleware handles the data synchronization and coordination of the processing units. This component further consists of four sub-components: messaging grid, data grid, processing grid, and deployment manager.
The messaging grid manages input requests to the system. It forwards the request to the processing unit that is able to process this request. It also keeps track of the session state of the request’s client. This sub-component is usually implemented as a typical web server with load balancing capabilities.
As mentioned above, each processing unit has an in-memory data grid. However, for large-scale applications that require the use of distributed cache, a data grid is sub-component is also placed within the virtualized middleware. This data grid is responsible for ensuring synchronous data replication between the processing units that contain the same named cache. For example, when one processing unit makes a change to the cache named CustomerProfile, that change is propagated to all of the other processing units that contain the same cache, so that all processing units will always remain in sync with each other.
The processing grid is an optional sub-component that orchestrates multiple processing units that are involved in handling a single request. For requests that require the coordination between multiple processing units, the processing grid orchestrates that communication between those processing units.
The deployment manager manages the startup and shutdown of processing units based on load conditions. It monitors response times and user loads, and starts up new processing units when load increase, and shuts down processing units when load decreases.
Data Pumps
Processing units do not directly read from and write to a database. Instead, they use data pumps to send data in an asynchronous way. Whenever a processing unit receives a request that updates its cache, it will send that update to the database through the data pump. When sending data updates, it is important to guarantee delivery and preserve message order, as well as decouple between the processing unit and the data writer, so that if the data writer is not available, the data update can still eventually be completed. This is why delivering data through messages in an asynchronously way is the best practice.
Data Writers
The data writer accepts messages from the data pump and updates the data in the database. Data writers are usually implemented as services, applications, or data hubs. Depending on the load of write requests, there may be a single data writer that accepts messages from all of the data pumps in a given domain, or there may be separate data writers for each data pump.
Data Readers
In space-based architecture, because data is replicated in the in-memory caches of processing units, there is not a need to read directly from the database. However, there are three situations where reading from the database is needed, and in these situations, a data reader is used:
- All processing units that contain the same named cache have crashed
- A redeployment of all processing units within the same named cache
- Retrieving archive data not contained in the replicated cache
The data reader accepts read requests and performs database queries to retrieve the data needed and sends that data to the processing units. The data coming from the data reader is sent to a reverse data pump, and the processing unit receives the data from the reverse data pump and loads it into its cache. After the cache is updated, the synchronization process begins.
Like data writers, data readers can also be domain-based or dedicated to a specific set of processing units. They are also implemented as services, applications, or data hubs.
Trade-Offs
Advantages
- The space-based architecture style has very good performance due to the use of in-memory data caching and removing the database as a bottleneck.
- It is highly scalable and elastic because processing units can be easily added or removed based on the varying load.
Disadvantages
- A space-based architecture is very complex to implement and expensive to maintain.
- Due to its complexity, testing is also very difficult, especially since this architecture is designed to handle high loads, so stress testing is very important but also very complicated and expensive to do.
