In this chapter
We'll name the real, accumulating cost of database-per-purpose architecture — operational complexity and data duplication, across eight individually well-justified systems — and revisit polyglot persistence honestly, at the cost it actually carries once practiced consistently.
The Problem in Real Life
Sarah sits down to write up GreenMart's actual infrastructure for a budget review, and starts listing what's actually running: MongoDB for the catalog, Redis for cache and sessions, DynamoDB for fleet tracking, Cassandra for sensor data, a graph database for fraud detection, a search engine for the catalog, a vector database for the shopping assistant, a realtime sync layer for live order tracking.
Eight systems. Eight logins. Eight things that can each, independently, break at 2am. Every single one of them was the right, deliberate choice when GreenMart adopted it — this course argued for each one, one Act at a time. Sarah still isn't sure the total adds up to something sustainable.
Every single one of these was the right call on its own. Together, I'm not sure anymore.
Sarah
The Right Tool, One at a Time vs. All of Them, At Once
Eight right choices, one real team
Every system was individually justified — the operational weight only shows up once they all exist together.
Operational complexity scales with count
Monitoring, backups, upgrades, on-call knowledge — a real tax per system, almost independent of how well-chosen each one was.
Data duplication compounds quietly
The same core facts, copied in different shapes across systems — each copy genuinely needed, each one more place to keep honestly in sync.
Polyglot persistence, honestly revisited
Correct at every individual step — and the accumulated weight of those correct steps is a real, separate cost worth reckoning with.
The Cost of Specialization
This is database-per-purpose architecture, named directly: exactly what this whole course has spent ten Acts building, one deliberate, well-justified specialist database per real problem. It's also genuinely expensive in a way no single Act's own incident ever surfaced, because that cost only shows up once all of them exist together, run by the same small team.
Operational complexity is the honest name for that cost: every one of these systems needs its own monitoring, its own backup strategy, its own upgrade schedule, its own on-call knowledge — a real, ongoing tax that scales with the number of systems, almost independent of how well-chosen each individual one was.
| System | What It's For | Who Actually Knows It Well |
|---|---|---|
| MongoDB | Product catalog | Most of the team |
| Redis | Cache & sessions | Whoever's on call |
| DynamoDB | Fleet tracking | One person, mostly |
| Cassandra | Sensor telemetry | Whoever set it up |
| Graph database | Fraud detection | One person, mostly |
| Search engine | Product search | The search-adjacent folks |
| Vector database | Shopping assistant | Whoever's newest |
| Realtime sync layer | Live order tracking | Whoever's on call |
Eight real, well-justified choices — and eight real, separate things a small team now has to keep running, upgraded, and understood, all at once.
Data duplication compounds this quietly: the same core facts about a customer or an order often end up copied, in a different shape, into several of these systems — the catalog in MongoDB, a search-optimized copy in the search engine, an embedding in the vector database — each genuinely necessary for its own access pattern, and each one more copy that can drift, another place the "same" fact has to be kept honestly in sync.
Polyglot persistence — Act 1's own term, introduced as the right instinct — is the actual name for what GreenMart has been practicing this whole course: using several databases, each for what it's genuinely best at. This chapter isn't taking that back. It's the honest continuation of it: polyglot persistence was correct at every individual step, and the accumulated operational weight of all those correct steps together is a real, separate cost that has to be reckoned with on its own terms, not assumed away just because each individual choice was sound.
Key Takeaway
Real systems don't always fit neatly into one database category — and the honest cost of taking that seriously, one right tool at a time, is a real operational weight that only becomes visible once all those right tools exist together. Being correct about every individual choice doesn't make the total free.
Why This Matters
This is the actual, honest motivation for the rest of this Act — not a change of mind about any earlier Act's choice, but a genuine, separate question this course hasn't asked yet: is there a way to keep most of what specialization bought GreenMart, while paying less of this specific, accumulating cost?
GreenMart now has an honest name for a real cost every earlier Act's own individually-correct decision quietly added to. Whether a single system can genuinely offer more than one of these database "shapes" at once — and what that would actually buy back — is exactly where the next chapter goes.