Chapter II · Area 06 of 12
The Question for Our ShopWho owns the order tables when all modules share a database?
Here you will find approaches for data ownership, storage and reliable state changes.
9 Building blocks
Starting hereData ownershipWho owns the data, and where does it live?
Order owns its tables; product search and images live in suitable stores.
What must stay consistent together?
B-1042 and the outbox entry commit together; as separate services, stock and payment would need a saga.
How is data distributed and access accelerated?
Read replica for customer service, partitions by customer ID, cache in the catalogue.
Known names – and where they are
Data ownership clarifies who is responsible for rules and state. Persistence and polyglot persistence choose the stores, partitioning splits them. Transactions and consistency govern changes, a saga links several; replication and caching keep copies available.
Here you clarify in the shop who owns the order tables, what must hold together when something changes, and how data is distributed and sped up. That tells you who may change state. Each building block shows its theme at our shop.
This is what you learnYou can specify exactly one responsible module for order, payment and inventory data.
In the shopIn the modular monolith, tables are located in a database, but remain assigned to individual modules. Shared storage does not override data sovereignty.
Data ownership OpenThis is what you learnYou can select a storage model for order letters and product search based on the access pattern.
In the shopOrders require nuclear status and position changes. Product search requires flexible full text queries across descriptions and categories.
SQL & NoSQL OpenThis is what you learnYou can determine which order changes belong atomically in a local transaction.
In the shopThe checkout stores order B-1042 with position P-7 and order amount in the shop database. The charge to the payment provider is an external call.
Transaction boundaries OpenThis is what you learnYou can formulate different visibility commitments for inventory reservation and customer overview.
In the shopThe warehouse reservation must check the current stock binding. A customer service overview may show the new shipping status a few seconds later.
Consistency models OpenThis is what you learnYou can explain why a copy of the reader can show an older order status immediately after a change.
In the shopVariant: The shop uses a reader copy of the order database for customer service queries in order to keep many queries away from the writing system.
Replication OpenThis is what you learnYou can select a partition key and recognize a cross-partition query.
In the shopVariant: With a strong increase in order volume, the shop distributes orders according to customer ID on three partitions. The remaining modules remain in the modular monolith.
Partitioning OpenThis is what you learnYou can set an up-to-date rule for each product description, price and stock.
In the shopThe catalogue shows product texts, prices and available quantities. These values change different times and have different consequences when obsolete.
Caching OpenThis is what you learnYou can assign each memory used an independent task and a significant source.
In the shopVariant: The grown shop keeps orders relational, searches for products in a search index and stores product images in an object memory. The shop remains technically modular.
Polyglot Persistence OpenThis is what you learnYou can arrange the local steps and appropriate compensations for a failed order process.
In the shopVariant: Warehouse and payment run as separate services, because independent operation was technically justified. Order coordinates the reservation and the externally connected payment provider.
Saga OpenThese areas are technically directly related to Data & state together.