Chapter 16 — Space-Based Architecture Style

Core ideas

• Built for extreme, variable scalability and elasticity by removing the central database from the request path (the DB is the usual bottleneck). Name comes from tuple space / shared memory (“the space”).
• Components: processing units (contain app logic + in-memory data grid / replicated cache), virtualized middleware (messaging grid, data grid, processing grid, deployment manager), and data pumps feeding a data writer that asynchronously persists to the actual database (with a data reader for rehydration).
• Reads/writes hit in-memory replicated data; the real DB is updated asynchronously → very high throughput, elastic scale-out. Eventual consistency and cache/data collision are the hard parts.

Trade-offs / when to use

For unpredictable, high-volume, spiky load (ticketing, online auctions, flash sales, concert/hotel booking). Extremely high scalability/elasticity/performance; low simplicity, high cost, and hard testability, plus eventual-consistency complexity.