Database per service pattern in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a microservice with its own database.

Microservices

class OrderService {
    constructor() {
        this.db = new [1]();
    }
}

Drag options to blanks, or click blank then click option'

AOrderDatabase

BCommonStorage

CSharedDatabase

DGlobalDB

Attempts:

3 left

💡 Hint

Common Mistakes

Using a shared or global database instead of a service-specific one.

The Database per service pattern means each microservice has its own dedicated database. Here, OrderDatabase represents the database specific to the OrderService.

2fill in blank

medium

Complete the code to ensure data isolation between services.

Microservices

function getUserData() {
    return [1].query('SELECT * FROM users');
}

Drag options to blanks, or click blank then click option'

ASharedDB

BGlobalUserDB

CUserServiceDB

DCommonDB

Attempts:

3 left

💡 Hint

Common Mistakes

Querying a shared or global database causing data coupling.

Each microservice should query its own database to maintain data isolation. Here, UserServiceDB is the database dedicated to the UserService.

3fill in blank

hard

Fix the error in the service communication to avoid direct database sharing.

Microservices

class PaymentService {
    constructor() {
        this.db = new [1]();
    }

    processPayment() {
        // Should not access OrderService database directly
        this.db.query('UPDATE orders SET status = "paid" WHERE id = 123');
    }
}

Drag options to blanks, or click blank then click option'

APaymentDatabase

BOrderDatabase

CSharedDatabase

DGlobalDB

Attempts:

3 left

💡 Hint

Common Mistakes

Using another service's database directly causing tight coupling.

PaymentService must use its own database (PaymentDatabase) and communicate with OrderService via APIs, not by accessing its database directly.

4fill in blank

hard

Fill both blanks to implement service communication without sharing databases.

Microservices

class InventoryService {
    constructor() {
        this.db = new [1]();
    }

    updateStock(orderId) {
        // Notify OrderService via [2]
        this.notifyOrderService(orderId);
    }
}

Drag options to blanks, or click blank then click option'

AInventoryDatabase

BDirectDBAccess

CMessageQueue

DSharedDatabase

Attempts:

3 left

💡 Hint

Common Mistakes

Using shared databases or direct DB access for communication.

InventoryService uses its own InventoryDatabase and communicates with OrderService through a MessageQueue, avoiding direct database sharing.

5fill in blank

hard

Fill all three blanks to implement a microservice with isolated database and API communication.

Microservices

class ShippingService {
    constructor() {
        this.db = new [1]();
    }

    notifyOrderService(shippingId) {
        fetch(`http://orderservice/api/orders/[2]`, {
            method: '[3]',
            body: JSON.stringify({ shippingId })
        });
    }
}

Drag options to blanks, or click blank then click option'

AShippingDatabase

BupdateShippingStatus

CPOST

DSharedDB

Attempts:

3 left

💡 Hint

Common Mistakes

Using shared databases or incorrect HTTP methods.

ShippingService uses its own ShippingDatabase. It communicates with OrderService by calling the updateShippingStatus API endpoint using the POST method, following the database per service pattern.

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