Vendor Lock-In, Compliance & Future Growth

In this chapter

We'll meet vendor lock-in, compliance, backup/recovery, failure tolerance, future growth, and polyglot persistence — the long-term requirements that close out a full workload analysis.

9–11 min

The Problem in Real Life

Every requirement so far has been about today — today's shape, today's promises, today's scale, today's team. Mike's last question looks the other direction entirely: what happens years from now, when today's decision is old news?

Sarah has one more category left, and it's the one every earlier Act quietly assumed rather than named directly.

Fine for today. What does this decision cost us five years from now?

Mike

What Today's Choice Costs Later

Vendor lock-in is a real, weighable cost

Not a reason to avoid managed services outright — a real trade-off to accept knowingly, not discover later.

Polyglot persistence means the answer might be two databases

Act 11's own term — sometimes the honest answer is admitting a workload has two real shapes, not one.

Six real, separate long-term questions, closing out the full workload-analysis picture before GreenMart moves from gathering facts to actually deciding anything.

On getting stuck. Vendor lock-in asks how hard it would be to leave a choice later — a fully proprietary managed service can be wonderful to run and genuinely painful to migrate away from if GreenMart's needs change. This isn't a reason to avoid managed services; it's a real cost to weigh honestly, eyes open.
On rules GreenMart doesn't get to choose. Compliance asks whether the data involved has real, external legal requirements — where it's allowed to physically live, who's allowed to access it, how long it must be kept. Geographic distribution (an earlier chapter) and compliance often collide directly: the fastest technical answer isn't always the legally allowed one.
On losing data for real. Backup/recovery asks a plain question every earlier Act's own persistence chapters have quietly assumed: if the absolute worst happens, how is the data actually recovered, and how much would genuinely be lost? Act 3's Redis persistence trade-offs and Act 12's RTO/RPO both already gave this a real, precise vocabulary.
On surviving failure, specifically. Failure tolerance asks how gracefully a system degrades when something breaks — not whether it ever will, but what happens honestly when it does, the same question every Act's own failure-handling chapter answered for one specific database.
On growing past today's plan. Future growth asks whether today's choice still makes sense at ten times today's scale, or in a market GreenMart hasn't expanded into yet — not a guess, but an honest, deliberate check against the scale requirements already named.
On not choosing just one. Polyglot persistence — Act 11's own locked term — is the honest reminder that the answer doesn't have to be a single database at all. Sometimes the right choice is admitting the workload has two genuinely different shapes, and using two well-chosen databases for the price of real, deliberate operational complexity, not one over-stretched database pretending to be simple.

For GreenMart's fleet-and-order requirement: acceptable, well-understood lock-in (DynamoDB is already in production use), no unusual compliance burden beyond standard data-residency rules already handled elsewhere, real backup/recovery already in place from Act 4's own patterns, honest failure tolerance already proven in production, real headroom for the expansion's planned growth, and — the polyglot question, asked honestly — no, this specific requirement doesn't need a second database; it's one coherent workload, not two disguised as one.

Key Takeaway

The requirements that matter five years from now — lock-in, compliance, recovery, failure tolerance, growth, and whether one database is even the right shape of answer — are just as real as today's technical requirements, and skipping them is exactly how a genuinely good decision today becomes a genuinely painful one later.

Why This Matters

A database chosen without asking these six questions can be entirely correct today and still become tomorrow's forced, expensive migration. This chapter is what makes that outcome a deliberate, informed risk GreenMart chose to accept — or didn't — instead of one nobody actually considered.

GreenMart now has the complete picture: data shape, promises, scale, operations, and long-term risk, all named honestly for the fleet-and-order requirement. The next chapter steps back from this one specific example to see how this same reasoning plays out across other real, well-known database comparisons.