Database Design Principles for Microservices: Independent Databases, Data Sharing Strategies, Backward‑Compatible Updates, and Saga Transactions

Independent Database

In microservice design, each service should have its own dedicated database that only the service itself can access, which optimizes service interfaces, simplifies error diagnosis, and enables full performance tuning control.

Shared Data

Static Tables

Static reference tables (e.g., country codes) can be duplicated as read‑only tables in each microservice to avoid costly cross‑service joins, provided the schema and data change infrequently.

Read‑Only Business Data Access

When a service needs to read dynamic business data from another service, the preferred method is a service call; if performance requires, a local read‑only copy can be created and kept in sync via event‑driven or RPC‑based synchronization.

Read‑Write Business Data Access

For scenarios where a service both reads and writes shared data, a master‑slave pattern is used: the original service owns the master table, while other services maintain read‑only copies (slaves) that are updated via broadcast messages; careful handling is needed because schema changes and data volume can introduce latency and interface leakage risks.

Direct Access to Other Databases

Directly accessing another service’s database is strongly discouraged, as it couples services tightly, makes deployments fragile, and hampers error isolation.

Backward‑Compatible Database Updates

When evolving a database schema in a microservice environment, changes must be backward compatible to avoid breaking other services; common techniques include adding nullable columns, soft‑deleting tables/columns, renaming fields with temporary duplication, and using views or triggers for seamless transitions.

Cross‑Service Transactions

Traditional two‑phase commit is unsuitable for microservices; the Saga pattern replaces it by defining compensating actions for each step, logging commands, and executing them forward for normal operation and backward for rollback, while accepting eventual consistency.

Microservice Splitting

To break a monolith into microservices, first extract a service’s code while keeping the original database, then gradually give the service its own database, ensuring data ownership and isolation; repeat this process for each new service.

Conclusion

Database design is a cornerstone of microservice architecture: each service should own an independent database, shared data should be accessed via service calls or carefully managed read‑only copies, schema changes must be backward compatible, and cross‑service transactions are best handled with the Saga pattern.