Break a Shared Database

The Order service and the Billing service — owned by two different teams — both read and write the same shared database. A schema change by one team breaks the other, and the database is a single point of failure for both. Decouple their data ownership.

Context

A shared database couples services: any schema change forces cross-team coordination, and the DB is a shared single point of failure. Database-per-service gives each service exclusive ownership of its data, so teams deploy independently. Cross-service reads go through APIs or events. The trade-off is distributed consistency and some controlled data duplication.

Requirements

•Give each service its own database and remove the shared one
•Each service owns and writes only its own data
•Cross-service data is exchanged via API calls or events — not shared tables

Non-Functional Requirements

•A schema change in one service must not require coordinating with another team

Constraints

•Focus on data ownership and topology — ignore data migration mechanics and consistency tuning

Evaluation Criteria

Evaluation criteria and weights will be revealed after you submit your solution. This ensures a fair assessment of your design skills.

Ready to solve this challenge?

Draw your architecture diagram, explain your design decisions, and get AI-powered feedback.

For the best experience, design challenges on a desktop or tablet — drawing the architecture on a phone is hard.

Start drawing nowNo account needed to draw. Sign up only to see your score (2 free evaluations).Already have an account? Sign in