Software Architecture
The Limitations of Traditional CRUD Application
The vast majority of web applications are built around the familiar CRUD model: Create, Read, Update, and Delete. The status of an entity (for example, the balance of a bank account) is stored in a database table, and changes overwrite the existing row in the database. While this suffices for simple information systems, you lose out with a UPDATE action the most valuable information of your company: intent and history. If a customer changes an address in the system, the old address is gone forever. In critical systems such as the banking sector, accounting packages, and complex supply chains, this destructive form of data storage (where history is lost) is unacceptable. The solution to this lies in two advanced architecture patterns: CQRS and Event Sourcing.
CQRS: Separating Commands and Queries
The Command and Query Responsibility Segregation (CQRS) architecture states that the data structure and processes used for the read data (Queries) must be fundamentally separated from the data structures and processes that data change (Commands). In a complex e-commerce environment, viewing a product catalog (Query) requires lightning-fast searches based on dozens of filters, and this action is executed thousands of times per second. Placing an order (Command), however, requires heavy business logic, inventory control, and transactional security, but happens much less frequently.
By decoupling the Read Model from the Write Model, you can scale and optimize them independently. The Command side communicates with a relational database to securely validate business rules, while the Query side writes data to a fully ‘flat’, denormalized view in Elasticsearch or a caching layer (such as Redis), ready to be sent directly to the customer’s screen.
Event Sourcing: Capturing the Intent
Event Sourcing is often inextricably linked to CQRS. Instead of storing the current ‘status’, Event Sourcing stores only the events which have led to the current status, in the form of an immutable (append-only) list (an Event Stream). Take a bank account: instead of storing the ‘Account’ table with the balance €150, the system stores the following list of events:
AccountOpened (Starting Balance: 0)AmountDeposited (Amount: 200)Amount Written Off (Amount: 50)
To determine the current balance (status), the system rehydrates these events in the software by simply playing them back from start to finish (replay). The current balance is therefore always calculated and never hardcoded as the absolute source of truth.
Complexity vs. Profit
The benefits of this system are phenomenal. It offers a 100% irrefutable, cryptographic audit trail (mandatory in finance). With ‘Time-Travel Debugging’, developers can literally rewind the system to the state of an object on an exact date three years ago. Furthermore, it enables companies to introduce new reporting systems (Materialised Views) retrospectively that analyze the entire historical Event Stream.
However, CQRS and Event Sourcing introduce an extreme degree of complexity, such as Eventual Consistency, handling failing networks (sagas), and ‘upgrading’ events as the structure changes (event versioning). It is an architecture reserved for complex business domains that fail with standard relational models. Discover architecture strategies at AG Connect.
Next: Go (Golang): The Backend Language for High-Performance Cloud Infrastructure
