Bird
Raised Fist0
Microservicessystem_design~5 mins

Database per service pattern in Microservices - Cheat Sheet & Quick Revision

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

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
Recall & Review
beginner
What is the Database per service pattern in microservices?
It is a design approach where each microservice has its own separate database. This means services do not share a database, helping to keep them independent and loosely coupled.
Click to reveal answer
beginner
Why does each microservice have its own database in the Database per service pattern?
To ensure that services are independent and changes in one service's database do not affect others. This improves scalability, fault isolation, and allows teams to choose the best database type for their service.
Click to reveal answer
intermediate
What is a common challenge when using the Database per service pattern?
Maintaining data consistency across services can be difficult because each service manages its own data. This often requires using asynchronous communication or eventual consistency techniques.
Click to reveal answer
intermediate
How does the Database per service pattern improve fault isolation?
If one service's database fails or has issues, it does not directly impact other services because they use separate databases. This limits the blast radius of failures.
Click to reveal answer
intermediate
Give an example of how different microservices might use different types of databases in the Database per service pattern.
One service might use a relational database for structured data, while another uses a NoSQL database for flexible document storage. This allows each service to pick the best tool for its needs.
Click to reveal answer
What is the main benefit of the Database per service pattern?
AAll services share the same database
BServices are independent and loosely coupled
CIt simplifies data consistency across services
DIt requires fewer databases overall
Which challenge is common with the Database per service pattern?
AData consistency across services
BSingle point of failure
CLimited scalability
DTight coupling of services
How does the Database per service pattern affect fault tolerance?
AReduces the number of databases needed
BIncreases risk of cascading failures
CImproves fault isolation between services
DMakes all services dependent on one database
What is a typical way to handle data consistency in this pattern?
AUse synchronous database transactions across services
BUse a single shared database
CAvoid communication between services
DUse asynchronous communication and eventual consistency
Which statement about Database per service pattern is FALSE?
AServices share a common database schema
BEach service can choose its own database type
CIt supports polyglot persistence
DIt helps teams work independently
Explain the Database per service pattern and its main advantages in microservices architecture.
Think about how separating databases helps services work independently.
You got /4 concepts.
    Describe the challenges of data consistency in the Database per service pattern and common solutions.
    Consider how services communicate to keep data aligned.
    You got /4 concepts.

      Practice

      (1/5)
      1. What is the main advantage of the Database per service pattern in microservices architecture?
      easy
      A. It reduces the number of databases needed in the system.
      B. All services share the same database for easier data management.
      C. Each service can be developed, deployed, and scaled independently.
      D. It allows direct database access between services.

      Solution

      1. Step 1: Understand the pattern's goal

        The Database per service pattern means each microservice owns its own database to avoid tight coupling.

      2. Step 2: Analyze the benefits

        This independence allows each service to be developed, deployed, and scaled without affecting others.

      3. Final Answer:

        Each service can be developed, deployed, and scaled independently. -> Option C

      4. Quick Check:

        Service independence [OK]
      Hint: Database per service means independent databases per microservice [OK]
      Common Mistakes:
      • Thinking all services share one database
      • Assuming database sharing improves independence
      • Believing it reduces total databases
      2. Which of the following is the correct way for microservices to access data in the Database per service pattern?
      easy
      A. Directly query another service's database.
      B. Use database triggers to sync data between services.
      C. Share a common database connection pool.
      D. Use APIs to communicate and request data from other services.

      Solution

      1. Step 1: Recall communication rules in this pattern

        Services do not share databases; they communicate via APIs to maintain independence.

      2. Step 2: Identify correct data access method

        Using APIs ensures loose coupling and clear service boundaries.

      3. Final Answer:

        Use APIs to communicate and request data from other services. -> Option D

      4. Quick Check:

        API communication [OK]
      Hint: Microservices talk via APIs, not direct DB access [OK]
      Common Mistakes:
      • Trying to query other service databases directly
      • Assuming shared connection pools exist
      • Using database triggers for cross-service sync
      3. Consider two microservices: OrderService and InventoryService, each with its own database. If OrderService needs to check stock before placing an order, what is the correct flow?
      medium
      A. OrderService sends an API request to InventoryService to get stock information.
      B. InventoryService pushes stock updates to OrderService's database.
      C. OrderService writes stock info to its own database and reads from there.
      D. OrderService queries InventoryService's database directly to check stock.

      Solution

      1. Step 1: Identify data ownership

        InventoryService owns stock data in its own database; OrderService cannot access it directly.

      2. Step 2: Determine communication method

        OrderService must call InventoryService's API to get current stock info.

      3. Final Answer:

        OrderService sends an API request to InventoryService to get stock information. -> Option A

      4. Quick Check:

        API call for data [OK]
      Hint: Always use API calls to get data from other services [OK]
      Common Mistakes:
      • Direct DB queries between services
      • Duplicating data in multiple databases
      • Relying on push updates to other service DBs
      4. A developer tries to implement the Database per service pattern but notices data inconsistency between services. What is the most likely cause?
      medium
      A. Services are sharing the same database schema.
      B. Services are directly querying each other's databases.
      C. Services communicate asynchronously via APIs.
      D. Each service has its own database and communicates via APIs.

      Solution

      1. Step 1: Identify incorrect practice

        Directly querying another service's database breaks independence and can cause stale or inconsistent data.

      2. Step 2: Understand correct communication

        Services should communicate via APIs to keep data consistent and boundaries clear.

      3. Final Answer:

        Services are directly querying each other's databases. -> Option B

      4. Quick Check:

        Direct DB queries cause inconsistency [OK]
      Hint: Avoid direct DB queries between services to prevent inconsistency [OK]
      Common Mistakes:
      • Assuming shared schema is the problem
      • Thinking async API calls cause inconsistency
      • Believing separate DBs cause inconsistency
      5. You are designing a microservices system with the Database per service pattern. How can you ensure data consistency across services when a transaction involves multiple services?
      hard
      A. Implement eventual consistency using event-driven communication and compensating actions.
      B. Use distributed transactions with two-phase commit across all databases.
      C. Allow services to share a single database to simplify transactions.
      D. Synchronize databases by copying data between services periodically.

      Solution

      1. Step 1: Understand distributed transaction challenges

        Two-phase commit is complex and reduces service independence, so it's rarely used in microservices.

      2. Step 2: Identify best practice for consistency

        Event-driven communication with eventual consistency and compensating actions allows services to stay independent and handle failures gracefully.

      3. Final Answer:

        Implement eventual consistency using event-driven communication and compensating actions. -> Option A

      4. Quick Check:

        Event-driven eventual consistency [OK]
      Hint: Use events and compensations for cross-service consistency [OK]
      Common Mistakes:
      • Trying distributed two-phase commit in microservices
      • Sharing a single database defeats independence
      • Periodic data copying causes stale data