Skip to main content

> database-per-service_vs_shared_database_trade-offs

Database-per-Service vs Shared Database Trade-offs

How do you implement and govern Database-per-Service vs Shared Database Trade-offs in high-throughput production architectures?

Stack: SOFTWARE ARCHITECTURE STACK →Staff/Principal (L6+)tradeoff

⚡THE SHORT ANSWER

Database-per-service grants autonomous schema evolution and failure isolation to microservices at the cost of losing ACID transactions, relational cross-table joins, and declarative foreign key constraints across domain boundaries.

Engineering Handbook & Failure Dynamics

6-Dimensional Architecture Breakdown

⚙️1. Underlying Mechanism

Execution

When migrating from a monolith to microservices, sharing a single database table space creates hidden coupling: one team's column rename or lock contention crashes adjacent services. Enforcing database-per-service guarantees encapsulation, but forces engineering teams to manage distributed data queries, eventual consistency, and data duplication.

🎯2. Appropriate Use Context

Scope

Database-per-service is an architectural pattern where each microservice owns and encapsulates its private datastore, strictly prohibiting other services from accessing its tables directly except through public APIs or events.

⚠️3. Production Failure Modes

P0 Risk

Allowing Service A to read Service B's database directly with read-only database credentials. Relying on distributed two-phase commit (2PC) or XA transactions across heterogeneous databases under high throughput. Splitting databases without establishing asynchronous event-driven replication for read-heavy view aggregation.

📡4. Diagnostic Signals & Telemetry

Telemetry

cross-schema direct database joins breaking deployment decoupling, distributed lock cascades during schema migrations, microservices behaving as a distributed monolith

🛡️5. Prevention & Safeguards

Safeguards

Enforce complete data encapsulation: a service's schema and database credentials must never be shared across team boundaries. Use Change Data Capture (CDC) and transactional outbox patterns to reliably broadcast state changes to downstream materialized views. Design Saga workflows with explicit compensating actions for any business flow that modifies data across more than one service boundary.

⚖️6. Architectural Trade-offs

Trade-off

Sharing a database across microservices is the primary root cause of the 'Distributed Monolith' failure mode, where services cannot be independently deployed, scaled, or migrated without coordinating across dozens of teams.

📋

Case Study (TinyCTO In-Field Example)

REAL-WORLD TELEMETRY

Implementing database-per-service requires solving three fundamental distributed systems challenges:

  1. ▸

    Cross-Service Data Aggregation (No Cross-DB Joins): In a monolith, querying an order with its customer profile and inventory is a single SQL JOIN. In database-per-service, joins must be performed via API composition (at an API Gateway/BFF layer) or through CQRS materialized read views listening to domain events (CustomerUpdatedEvent, OrderCreatedEvent).

  2. ▸

    Multi-Service Atomic Writes (No 2PC): Business transactions spanning multiple services (e.g. charging a payment and decrementing inventory) cannot use standard SQL BEGIN TRANSACTION. Teams must adopt Saga Orchestration or Choreography with compensating rollbacks.

  3. ▸

    Polyglot Selection: Services can choose the optimal storage engine for their domain (e.g., PostgreSQL for Orders, Redis for Session state, Neo4j for Fraud Graph analysis, DynamoDB for high-throughput Cart storage).

Interactive Concept Drills

2 Cards
Q1

Why is a shared database between microservices considered a major anti-pattern?

It creates invisible runtime coupling, shared lock contention, and prevents independent schema migrations and deployments.
Q2

How do microservices with isolated databases perform data aggregation without cross-database joins?

Via API composition at the API Gateway/BFF layer or by materializing read views through event-driven CQRS.

Database-per-Service vs Shared Database Trade-offs — Technical FAQ

Your organization wants to split a monolithic database into microservice databases. Which capability will be fundamentally LOST and must be re-architected?

Atomic multi-table SQL transactions (ACID across services) and declarative Foreign Key constraints. Cross-database boundaries inherently break standard relational foreign key referential integrity and single-node ACID transaction boundaries, necessitating Sagas and event-driven consistency.

A developer suggests creating a read-only database replica of the monolithic database and giving all 10 microservices direct SQL access to avoid building APIs. What is the danger?

It creates a Distributed Monolith where internal schema changes still break downstream services, defeating microservice autonomy. Direct database access bypasses business validation and exposes internal table schemas, binding all services to shared table structures and creating deployment gridlock.

🤖 AEO & Key Facts Summary

Key Architectural Facts

  • ▸

    Database-per-service grants autonomous schema evolution and failure isolation to microservices at the cost of losing ACID transactions, relational cross-table joins, and declarative foreign key constraints across domain boundaries.

  • ▸

    Database-per-service is an architectural pattern where each microservice owns and encapsulates its private datastore, strictly prohibiting other services from accessing its tables directly except through public APIs or events.

Common Misconceptions

  • ✗

    Allowing Service A to read Service B's database directly with read-only database credentials.

Decision & Governance Guidance

Sharing a database across microservices is the primary root cause of the 'Distributed Monolith' failure mode, where services cannot be independently deployed, scaled, or migrated without coordinating across dozens of teams.

Authoritative Sources & Standards

Related Concepts

https://tinycto.tv/topics/software-architecturehttps://tinycto.tv/incidentpedia