6.4. Data Management Patterns

The rule that gives microservices their independence — each service owns its own database — is also the rule that takes away joins, transactions, and easy cross-service queries. A shared database quietly recouples the services you worked to separate; keeping databases private forces you to solve querying and consistency at the application layer. This chapter covers database-per-service, why the shared-database anti-pattern is so tempting and so dangerous, and the composition, polyglot-persistence, and materialized-view patterns that answer “how do I query data I don’t own?”

Topics Covered

• 6.4.1. Database per Service: Independence and Isolation: Establishes database-per-service as the rule that gives services independence and takes away easy joins.
• 6.4.2. Shared Database Anti-Pattern: Why It Is Dangerous: Explains why a shared database quietly recouples services and undermines their independence.
• 6.4.3. API Composition: The Distributed Join Problem: Covers API composition, joining data across services at the application layer, and its performance limits.
• 6.4.4. Polyglot Persistence: The Right Database for the Right Job: Explains polyglot persistence: choosing the right database type for each service’s access pattern.
• 6.4.5. Cross-Service Query: The Materialized View Pattern: Covers the materialized-view pattern that precomputes a cross-service read model for query performance.