Undertaking a significant software project requires planning well beyond the foresight horizon. How the business will change, how the project’s success will feed back into its requirements, how IT will change are all factors that make a thorough up-front design impractical.In order to address this uncertainty we need to put in place an architecture that is flexible enough to deal with the unknowns without requiring a significant rebuild to accommodate that change.
Rather than making more powerful computers (vertical scalability) we need to spread the workload across multiple independent nodes based on standard commodity hardware.This requires an architecture that maximises parallelism. Nodes should not wait for each other and the number of nodes should be dynamically adjusted to the workload.
A system typically has to work with very different types of data, from the highly structured such as tabular data to semi-structured documents, to image and other raw file formats and even custom persisted data views that could be an aggregate of all of these.
Storing data pertaining to multiple clients in a single database significantly increases the risk of data breach and also makes it very difficult to analyse their storage requirements (and to bill accordingly).
The system is split between the command side which is responsible for actions and the query side which is responsible for data requests.The number and ratio of command and query handlers can be adjusted to match the needs of the underlying business process.
The common data container is used for reference data that is common to all clients. Each client has its own separate container for client specific data.Containers are independently secured to minimise data breach risk