Bird
Raised Fist0
Microservicessystem_design~7 mins

Why each service owns its data in Microservices - Why This Architecture

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Problem Statement
When multiple services share the same database or data store, changes by one service can unexpectedly break others. This tight coupling causes deployment delays, data corruption, and scaling problems because services depend on the same data structure and access patterns.
Solution
Each service manages its own private database or data store, owning its data exclusively. Services communicate with each other through APIs or events to share information, avoiding direct database sharing. This separation allows independent development, deployment, and scaling without risking data conflicts.
Architecture
┌─────────────┐       ┌─────────────┐       ┌─────────────┐
│ Service A   │       │ Service B   │       │ Service C   │
│ ┌─────────┐ │       │ ┌─────────┐ │       │ ┌─────────┐ │
│ │ DB A    │ │       │ │ DB B    │ │       │ │ DB C    │ │
│ └─────────┘ │       │ └─────────┘ │       │ └─────────┘ │
└─────┬───────┘       └─────┬───────┘       └─────┬───────┘
      │ API/Event            │ API/Event            │ API/Event
      └─────────────────────┴─────────────────────┴

This diagram shows three microservices, each with its own private database. They communicate only via APIs or events, never sharing databases directly.

Trade-offs
✓ Pros
Enables independent service deployment and scaling without affecting others.
Prevents data corruption and conflicts caused by shared database access.
Improves fault isolation; one service's data issues don't cascade.
Allows each service to choose the best database technology for its needs.
✗ Cons
Requires designing APIs or event contracts for data sharing, adding complexity.
Data duplication may occur, increasing storage and synchronization overhead.
Cross-service queries become harder, often requiring data aggregation layers.
Use when building microservices that require independent lifecycle, scalability, and fault isolation, especially at scale beyond hundreds of requests per second.
Avoid when the system is small with tightly coupled components or when strong transactional consistency across services is mandatory and cannot be handled via eventual consistency.
Real World Examples
Amazon
Each microservice owns its data to allow independent scaling and deployment, avoiding database contention and enabling rapid feature development.
Netflix
Services own their data stores to isolate failures and optimize data models per service, improving resilience and performance.
Uber
Separate data ownership per service helps manage complex domain boundaries and supports diverse data storage technologies.
Code Example
This code shows how sharing a database directly causes tight coupling and data conflicts. After applying the pattern, each service owns its data and communicates via events, enabling independent evolution and reducing risk.
Microservices
### Before: Two services sharing the same database table directly
class OrderService:
    def create_order(self, order_data):
        # Directly insert into shared orders table
        db.execute("INSERT INTO orders ...", order_data)

class PaymentService:
    def update_payment_status(self, order_id, status):
        # Directly update shared orders table
        db.execute("UPDATE orders SET payment_status=? WHERE id=?", (status, order_id))


### After: Each service owns its own database and communicates via API

# Order Service with private DB
class OrderService:
    def __init__(self, db, event_bus):
        self.db = db
        self.event_bus = event_bus

    def create_order(self, order_data):
        self.db.insert_order(order_data)
        # Notify Payment Service via event
        self.event_bus.publish('order_created', order_data)

# Payment Service with private DB
class PaymentService:
    def __init__(self, db):
        self.db = db

    def on_order_created(self, order_data):
        self.db.create_payment_record(order_data['id'])

    def update_payment_status(self, order_id, status):
        self.db.update_payment_status(order_id, status)

# Event bus simulates communication
class EventBus:
    def __init__(self):
        self.subscribers = {}
    def publish(self, event, data):
        for handler in self.subscribers.get(event, []):
            handler(data)
    def subscribe(self, event, handler):
        self.subscribers.setdefault(event, []).append(handler)

# Wiring up
# Assuming db instances are provided
order_db = ...  # some database instance for orders
payment_db = ...  # some database instance for payments

event_bus = EventBus()
order_service = OrderService(order_db, event_bus)
payment_service = PaymentService(payment_db)
event_bus.subscribe('order_created', payment_service.on_order_created)

# Explanation:
# The OrderService owns its orders database and publishes events.
# The PaymentService owns its payment database and reacts to events.
# No direct database sharing occurs.
OutputSuccess
Alternatives
Shared Database
Multiple services access the same database schema directly without data ownership boundaries.
Use when: Choose when the system is small, teams are tightly coordinated, and strong ACID transactions across services are required.
Database per Service with Shared Schema
Each service has its own database but shares the same schema and data model.
Use when: Choose when teams want some isolation but need uniform data structure for easier integration.
Summary
Sharing a database among services causes tight coupling and deployment risks.
Each service owning its data enables independent development, deployment, and scaling.
Services communicate via APIs or events to share data while maintaining ownership boundaries.

Practice

(1/5)
1. Why should each microservice own its own data instead of sharing a common database?
easy
A. To ensure services are independent and can evolve separately
B. To reduce the total amount of data stored in the system
C. To make it easier to write SQL queries across services
D. To allow all services to access data faster by sharing it

Solution

  1. Step 1: Understand service independence

    Each microservice owning its data means it can change its database without affecting others.
  2. Step 2: Recognize benefits of separate data ownership

    This independence improves scalability and reduces tight coupling between services.
  3. Final Answer:

    To ensure services are independent and can evolve separately -> Option A
  4. Quick Check:

    Service independence = D [OK]
Hint: Think about service independence and avoiding tight coupling [OK]
Common Mistakes:
  • Assuming shared databases improve performance
  • Believing data sharing reduces storage needs
  • Thinking SQL queries are easier with shared data
2. Which of the following is the correct way for microservices to access data owned by another service?
easy
A. Directly querying the other service's database
B. Sharing a common database schema
C. Using APIs or messaging to request data
D. Copying the entire database locally

Solution

  1. Step 1: Identify proper data access method

    Microservices should not access each other's databases directly to avoid tight coupling.
  2. Step 2: Recognize communication via APIs or messages

    Services communicate data through APIs or messaging systems to maintain independence.
  3. Final Answer:

    Using APIs or messaging to request data -> Option C
  4. Quick Check:

    Data access via APIs/messages = B [OK]
Hint: Remember: no direct DB access, use APIs or messages [OK]
Common Mistakes:
  • Trying to query another service's database directly
  • Assuming shared schema is best practice
  • Copying entire databases unnecessarily
3. Consider two microservices: Service A owns customer data, and Service B owns order data. Service B needs customer info to process orders. Which approach correctly respects data ownership?
medium
A. Service B queries Service A's database directly for customer info
B. Service B calls Service A's API to get customer info
C. Service B duplicates customer data in its own database
D. Service B uses a shared database for both customer and order data

Solution

  1. Step 1: Identify correct data access respecting ownership

    Service B should not access Service A's database directly or share databases.
  2. Step 2: Use API calls for data retrieval

    Calling Service A's API allows Service B to get needed data without breaking ownership rules.
  3. Final Answer:

    Service B calls Service A's API to get customer info -> Option B
  4. Quick Check:

    API calls respect ownership = A [OK]
Hint: Use APIs to get data from other services, not direct DB access [OK]
Common Mistakes:
  • Direct DB queries across services
  • Duplicating data causing inconsistency
  • Using shared databases breaking independence
4. A team notices that two microservices share a database schema and directly query each other's tables. What is the main problem with this design?
medium
A. It causes tight coupling and reduces service independence
B. It improves scalability by sharing data
C. It simplifies API design between services
D. It reduces the need for data synchronization

Solution

  1. Step 1: Analyze impact of shared database schema

    Sharing schema and direct queries create tight coupling between services.
  2. Step 2: Understand consequences on independence

    Tight coupling reduces the ability to change or scale services independently.
  3. Final Answer:

    It causes tight coupling and reduces service independence -> Option A
  4. Quick Check:

    Tight coupling problem = C [OK]
Hint: Shared DB means tight coupling, which is bad for microservices [OK]
Common Mistakes:
  • Thinking shared DB improves scalability
  • Assuming it simplifies API design
  • Believing it removes sync needs
5. You are designing a microservices system with three services: User, Inventory, and Order. Each service owns its data. How should you handle a scenario where the Order service needs to confirm inventory availability before placing an order?
hard
A. All services share a single database to simplify data access
B. Order service queries Inventory service's database directly to check stock
C. Order service duplicates inventory data locally and updates it periodically
D. Order service calls Inventory service's API to check stock availability

Solution

  1. Step 1: Respect data ownership in design

    Each service must own and manage its own data; direct DB queries or shared DB break this.
  2. Step 2: Use API calls for inter-service communication

    Order service should call Inventory service's API to get real-time stock info, ensuring data consistency and independence.
  3. Final Answer:

    Order service calls Inventory service's API to check stock availability -> Option D
  4. Quick Check:

    API communication respects ownership = A [OK]
Hint: Always use APIs for cross-service data, never direct DB access [OK]
Common Mistakes:
  • Direct DB queries breaking independence
  • Duplicating data causing stale info
  • Using shared DB increasing coupling