Three municipal teams keep one shared database schema “to keep transactions easy,” so every migration needs a coordinated release window. What is the main design cost of that shared-schema anti-pattern?
Select an answer to reveal the explanation.
Short Explanation
A shared schema is a single town ledger every department must revise together—migrations become city-wide events. You lose independent evolution and invite lock contention. Eventual consistency is often the price of separating ownership, not something a shared schema magically removes forever.
Full Explanation
One schema across services forces coordinated migrations and allows contention across team boundaries. That coupling is the persistence anti-pattern opposite of service-owned data. Shared schemas do not auto-deliver multi-region active-active, permanently eliminate consistency trade-offs, or mandate Functions-only runtimes.