Junior Level

Database per Service — each microservice has its own database, which no one else uses directly.

Cost: you can no longer do SELECT … JOIN between tables of different services. Instead — API calls or event-driven replication.

Order Service -> Order DB
User Service -> User DB
Payment Service -> Payment DB

Why:

• Independence — each service can change its schema without affecting others
• Isolation — one service’s DB going down doesn’t affect others
• Flexibility — different services can use different databases (SQL, NoSQL)

---

Middle Level

When NOT to use Database per Service

• Small team (2-3 devs) — can’t handle managing multiple databases
• Startup in validation phase — schema changes daily
• Strict consistency for reporting — difficult with eventual consistency

How services get each other’s data

1. API calls:

Order Service -> User Service API -> get user data

2. Event-driven:

User Service -> "UserUpdated" event -> Order Service listens and caches

3. CQRS:

(CQRS — Command Query Responsibility Segregation, separate models for writes and reads.)
(Materialized View — pre-computed data representation for fast queries.)
Write model -> Order DB
Read model -> Materialized view (from events)

Common mistakes

1. Shared database:

   Order Service -> User table directly
   Encapsulation violation -> coupling
   

---

Senior Level

Architectural Trade-offs

Database per Service	Shared Database
Full isolation	Simpler
Eventual consistency: when User Service updates data and publishes an event, Order Service receives it with a delay (ms or seconds). During this window, Order Service sees stale data.	ACID transactions
Complex cross-service queries	Cross-service JOINs
Independent deployment	Coordinated deployment

Production Experience

Polyglot persistence:

(Polyglot Persistence — using different DBMS for different tasks.)
User Service -> PostgreSQL
Session Service -> Redis
Analytics Service -> ClickHouse
Search Service -> Elasticsearch

Database per Service vs Schema per Service

You can have logical isolation (separate schemas) on one physical database server. This is a compromise: easier to operate, but less isolation when the server goes down.

Best Practices

✅ Each service — its own database
✅ API or events for data access
✅ Polyglot persistence when needed
✅ Eventual consistency

❌ Direct access to another service's database
❌ Shared database between services
❌ Distributed transactions without necessity

---

Interview Cheat Sheet

Must know:

• Database per Service — each microservice has its OWN database, no one else uses it directly
• Independence: each service changes its schema without others, isolation on DB failure
• Services get each other’s data via API calls, events, or CQRS
• Polyglot persistence — different services can use different DBMS
• Eventual consistency: another service’s data may be stale for ms-seconds
• Logical isolation (separate schemas) on one physical server is possible — a compromise
• NOT suitable for small teams (2-3 devs) and startups with frequent schema changes

Common follow-up questions:

• How to get another service’s data? API call (synchronous), event-driven (asynchronous), or materialized view (CQRS).
• What is polyglot persistence? User Service -> PostgreSQL, Session -> Redis, Analytics -> ClickHouse.
• Database per Service vs Schema per Service? Schema per Service — logical isolation on one server — easier to operate, but less isolation on server failure.
• When NOT to use it? Small team, startup, strict consistency for reporting.

Red flags (DO NOT say):

• “You can read from another service’s database directly” — encapsulation violation, coupling
• “Eventual consistency = data is always wrong” — no, it will become correct over time
• “JOINs between services are normal practice” — no, it’s an anti-pattern
• “Every service needs a separate database server” — no, you can use schemas on one server

Related topics:

• [[1. What is Saga pattern and when to use it]]
• [[3. How to implement distributed transactions in microservices]]
• [[14. What problems arise when using a shared database]]
• [[15. How to organize communication between microservices]]
• [[16. What is the difference between synchronous and asynchronous communication]]