Data Architecture for Software Architects

Part I. Architecting Operational Data

Operational systems are where data first enters into enterprise systems. They accept orders, reserve inventory, authorize payments, update customer accounts, issue purchase orders, pay suppliers and help in executing the work that keeps a business running. Their architecture is shaped by immediate concerns: correctness, latency, scalability, availability, concurrency, and the ability to evolve without disrupting day-to-day operations.

Part I focuses on this operational side of data architecture. We have separated it from analytical data architecture because operational workloads create a distinct set of architectural forces. The database that records an order is doing a different job from the warehouse that analyzes quarterly sales. The search index that helps a customer find a product is optimized differently from the system of record that maintains the product catalog. Bringing all these concerns together too early tends to blur important trade-offs.

The Chapter 2 chapter looks at one of the first techniques architects reach for when a single data store can no longer comfortably handle the workload. Partitioning can distribute storage and processing, it introduces partition keys, data locality, rebalancing, and cross-partition operations. Each option improves some operations while making others more difficult.Partitioning is therefore less about dividing data evenly and more about aligning data placement with business behavior.

The Chapter 3 ...