Space Based Architecture

Photo credit: https://en.wikipedia.org/wiki/Space-based_architecture

Like CQRS (Command Query Responsibility Segregation), this architecture is used for high scalability and performance.
In a typical setup there is usually a client, an application server and a database. Whenever load increases, we can increase the number servers handling the client requests, once we fix that we soon find that the application server handing all the business logic is now the bottleneck. Once we scale that up we are pass the bottleneck on to the database.
Unlike the previous layers, scaling up the database is very tough. Databases are not really meant to be scaled. Sure, there are solutions out there which try to address this, but it’s difficult and expensive.
This pattern tries to address that bottleneck – the database. In this architecture, there are 5 components:

1. Processing Unit
2. Middle ware
   1. Message grid
   2. Data Grid
   3. Processing Grid
   4. Deployment Manager

The processing unit is the component which houses the business application. Its complete with it’s own persistence store (the database) and is self sufficient.
Message Grid is responsible for orchestrating the various requests from client to the different processing units.
Data Grid: It’s responsible for keeping the data in sync within all the individual persistence stores in the processing units.
Processing Grid: Often the request is split between multiple processing units to get even better throughput. Processing grid is responsible for this.
Deployment Manager: As the load increases, it’s responsible for spawning up more processing units. Similarly when the load decreases, it’s responsible for getting the number of processing units down.
The reason why this architecture effectively solves the database bottleneck problem is that in this solution there is no common repository. Every processing unit has it’s persistence store. So the database never becomes a bottleneck here.
Also, as the load increases/decreases, the system scales accordingly.
So, both CQRS and Space Based Architecture support scalability by having multiple instances of the databases. The Space Based Architecture scales the system dynamically based on the load, however, with this additional power comes the additional complexity. If the load fluctuates a lot, then Space Based Architecture is the better option.

CQRS

Software architecture has evolved a long way from the standard 3 tier architecture. A lot of the previous architectures were optimized for the constraints present at that time like limited resources but with time such restrictions no longer apply.
The most promising of the new architecture is the Domain Centric Architecture which places domain right at the center of the architecture. But more on the domain driven design later.
Another interesting concept is CQRS – Command Query Responsibility Segregation. This is useful for creating a system optimized for performance. The principle is simple, keep the command and query separate.
Command is anything that changes the state of the system on the other hand query requests some information from the system. A query should never alter the state of the system and the command should ideally not return some information. Of-course, a strong distinction is not always possible, a command does often return whether it was successful or not but keeping them separate leads to a lot of benefits.
Code level:
CQRS should be even strived at a code level. A function responsible for fetching some information should never alter the state of the class. As the codebase grows, a public facing getter API can be called from different modules. It’s next to impossible to control that and other modules may not have enough information to identify when a simple get call ended up altering the state of system inadvertently.
Architecture level:
A lot of the features in the software are data-read heavy and usually a smaller set of features in the software actually update the data. If we keep them separate we can scale them independently. The ‘Query’ module having optimized for fast reads and ‘Command’ module optimized for writes. In a little more advanced version of CQRS, both the stacks can have independent databases. Every write into the main database is then synchronized with the database meant for ‘read’. For short duration these databases will be out of sync but this leads to highly performant systems and the performance won’t degrade as you scale the system.
There are downsides of it too. Implementing CQRS makes the architecture complex and should not be used if the performance and scalability are not the primary needs of the software. Also, the query and command stacks will have data which will be out of sync which leads to additional complexity in the system.