Shared database anti-pattern in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why is the shared database anti-pattern problematic in microservices?

Imagine multiple microservices directly accessing the same database schema. What is the main problem with this approach?

A It improves data consistency by centralizing all data access in one place.

B It creates tight coupling between services, making independent deployment and scaling difficult.

C It reduces network latency because services do not need to communicate over the network.

D It simplifies service design by removing the need for APIs.

💡 Hint

Think about how microservices should be independent and loosely coupled.

Sharing a database schema tightly couples microservices, which breaks their independence. This makes it hard to deploy or scale services separately and can cause data conflicts.

❓ Architecture

intermediate

Which architecture avoids the shared database anti-pattern?

Given a microservices system, which architecture best avoids the shared database anti-pattern?

A Each microservice owns its own database and communicates with others via APIs or messaging.

B All microservices connect to a single centralized database with shared tables.

C Microservices share a database but use different schemas within it.

D Microservices store data in a shared cache to reduce database load.

💡 Hint

Consider how services can remain independent and communicate safely.

Owning separate databases allows microservices to be independent and scale separately. Communication happens through APIs or messaging, not direct database sharing.

❓ scaling

advanced

What scaling issue arises from the shared database anti-pattern?

When multiple microservices share a single database, what is a common scaling problem?

A Network traffic between services increases due to database sharing.

B Each microservice can scale its database independently, improving performance.

C Data replication delays cause eventual consistency issues.

D The database becomes a bottleneck, limiting the ability to scale services independently.

💡 Hint

Think about what happens when many services rely on one database.

A shared database can become a single point of contention and bottleneck, preventing microservices from scaling independently.

❓ tradeoff

advanced

What is a tradeoff when avoiding the shared database anti-pattern?

Choosing separate databases per microservice avoids tight coupling but introduces what challenge?

A Data consistency becomes harder to maintain across services.

B Services become tightly coupled through the database schema.

C Deployment becomes slower due to shared database locks.

D Network latency is eliminated between services.

💡 Hint

Think about data synchronization when data is split across databases.

Separate databases improve independence but require careful design to keep data consistent across services, often using eventual consistency or messaging.

❓ component

expert

In a microservices system avoiding shared database anti-pattern, which component helps maintain data consistency?

When each microservice has its own database, which component is commonly used to keep data consistent across services?

A Direct database triggers that update other services' databases.

B A centralized monolithic database accessed by all services.

C Event-driven messaging system that publishes and subscribes to data changes.

D Shared cache layer that all services read and write to.

💡 Hint

Consider how services communicate asynchronously to sync data.

Event-driven messaging allows services to notify others about data changes, enabling eventual consistency without sharing databases.

Practice

1. What is the main problem caused by the shared database anti-pattern in microservices?

easy

A. Better fault isolation between services

B. Tight coupling between services due to shared data schema

C. Easier scaling of individual services

D. Improved performance by sharing data directly

Solution

1. Step 1: Understand the shared database anti-pattern

   This anti-pattern happens when multiple microservices use the same database schema directly.

2. Step 2: Identify the impact on service independence

   Sharing the database causes tight coupling, making services dependent on each other's data structure changes.

3. Final Answer:

   Tight coupling between services due to shared data schema -> Option B

4. Quick Check:

   Shared database = Tight coupling [OK]

Hint: Shared DB means tight coupling, breaking microservices independence [OK]

Common Mistakes:

• Thinking shared DB improves scaling
• Assuming shared DB isolates faults
• Believing shared DB simplifies service design

2. Which of the following is the correct way to avoid the shared database anti-pattern in microservices?

easy

A. Use a single database schema shared by all services

B. Store all data in a centralized monolithic database

C. Allow direct SQL queries from one service to another's database

D. Each service owns its own database and communicates via APIs

Solution

1. Step 1: Recall best practice for microservice data management

   Each microservice should have its own database to maintain independence.

2. Step 2: Identify the correct communication method

   Services communicate through APIs, not by sharing databases or direct queries.

3. Final Answer:

   Each service owns its own database and communicates via APIs -> Option D

4. Quick Check:

   Separate DB + APIs = Avoid shared DB anti-pattern [OK]

Hint: Separate DB per service + API calls avoid shared DB anti-pattern [OK]

Common Mistakes:

• Choosing shared schema for simplicity
• Allowing direct cross-service DB queries
• Centralizing all data in one DB

3. Consider two microservices, Service A and Service B, sharing the same database. Service A changes a table schema without informing Service B. What is the most likely outcome?

medium

A. Service B automatically adapts to the new schema

B. Service B continues working without issues

C. Service B experiences runtime errors due to schema mismatch

D. Both services improve performance

Solution

1. Step 1: Analyze the impact of schema change on shared DB

   When services share a database, schema changes affect all services using it.

2. Step 2: Predict Service B's behavior

   Service B expects the old schema; a change causes runtime errors like failed queries or crashes.

3. Final Answer:

   Service B experiences runtime errors due to schema mismatch -> Option C

4. Quick Check:

   Schema change + shared DB = runtime errors [OK]

Hint: Schema change in shared DB breaks other services [OK]

Common Mistakes:

• Assuming automatic schema adaptation
• Believing no impact on other services
• Thinking performance improves

4. You find that two microservices share a database causing tight coupling and deployment issues. Which change fixes this problem?

medium

A. Create separate databases and add API communication

B. Merge the two services into one monolith

C. Add more indexes to the shared database

D. Allow both services to write to the same tables

Solution

1. Step 1: Identify the root cause of tight coupling

   Sharing the same database schema causes deployment and coupling problems.

2. Step 2: Apply the correct fix

   Separating databases and using APIs decouples services and allows independent deployment.

3. Final Answer:

   Create separate databases and add API communication -> Option A

4. Quick Check:

   Separate DB + APIs fix shared DB anti-pattern [OK]

Hint: Separate DB + APIs fix tight coupling from shared DB [OK]

Common Mistakes:

• Merging services loses microservice benefits
• Adding indexes doesn't fix coupling
• Allowing shared writes keeps tight coupling

5. A company has three microservices sharing one database. They want to migrate to avoid the shared database anti-pattern. Which approach best balances data consistency and service independence?

hard

A. Split databases per service and use event-driven messaging for data sync

B. Keep shared database but add strict schema versioning

C. Merge all services into a single database schema with shared tables

D. Use direct SQL queries between services to keep data consistent

Solution

1. Step 1: Understand the trade-offs in migration

   Separating databases improves independence but can cause data consistency challenges.

2. Step 2: Choose a pattern that balances consistency and independence

   Event-driven messaging allows services to sync data asynchronously while keeping separate databases.

3. Final Answer:

   Split databases per service and use event-driven messaging for data sync -> Option A

4. Quick Check:

   Separate DB + events balance consistency and independence [OK]

Hint: Use separate DB + events for sync to avoid shared DB anti-pattern [OK]

Common Mistakes:

• Keeping shared DB limits independence
• Merging services loses microservice benefits
• Using direct SQL breaks service boundaries