Database per service pattern in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use the database per service pattern in microservices?

In a microservices architecture, why is it beneficial for each service to have its own database?

A It allows each service to be independently developed, deployed, and scaled without affecting others.

B It forces all services to share the same data schema, improving consistency.

C It reduces the total number of databases needed, lowering infrastructure costs.

D It ensures that all services access data through a single centralized database.

💡 Hint

Think about how independent services should be in microservices.

Each microservice having its own database allows it to evolve independently, avoiding tight coupling and enabling independent scaling and deployment.

❓ Architecture

intermediate

Identify the correct architecture for database per service pattern

Which diagram best represents the database per service pattern in microservices?

A All services connected to a central database cluster with shared tables.

B Multiple services connected to a single shared database instance.

C Multiple services each connected to their own separate database instances.

D One service connected to multiple databases, other services share one database.

💡 Hint

Remember the pattern means each service owns its data store.

In the database per service pattern, each microservice manages its own database, ensuring loose coupling and autonomy.

❓ scaling

advanced

Scaling challenges with database per service pattern

What is a common scaling challenge when using the database per service pattern?

A High risk of single point of failure because all services use one database.

B Difficulty in maintaining data consistency across multiple databases owned by different services.

C Inability to scale services independently due to shared database bottlenecks.

D Services cannot be deployed independently because they share the same database schema.

💡 Hint

Think about data that spans multiple services.

Because each service has its own database, keeping data consistent across services requires careful design, often using eventual consistency or event-driven approaches.

❓ tradeoff

advanced

Tradeoffs of database per service pattern

Which of the following is a tradeoff when adopting the database per service pattern?

A Improved service autonomy but increased complexity in cross-service queries.

B Simplified data management but reduced service independence.

C Lower infrastructure costs but higher risk of data corruption.

D Centralized data control but slower service deployment.

💡 Hint

Consider what happens when services need data from each other.

While each service controls its own data, querying across services becomes complex and may require additional mechanisms like APIs or event messaging.

❓ estimation

expert

Estimating database instances for microservices

You have 10 microservices, each following the database per service pattern. Each service requires 2 database instances for high availability. How many total database instances are needed?

A 10

B 12

C 30

D 20

💡 Hint

Multiply the number of services by the number of instances per service.

Each of the 10 services needs 2 instances, so total instances = 10 * 2 = 20.

Practice

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