Why each service owns its data in Microservices - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a microservice that owns its data store.

Microservices

class UserService {
    constructor() {
        this.database = new [1]();
    }
}

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

AUserDatabase

BSharedDatabase

CGlobalDB

DExternalDB

Attempts:

3 left

💡 Hint

Common Mistakes

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

The UserService should own its own database instance, here named UserDatabase, to ensure data ownership and isolation.

2fill in blank

medium

Complete the sentence to explain why each microservice owns its data.

Microservices

Each microservice owns its data to ensure [1] and avoid tight coupling between services.

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

Adata redundancy

Bdata consistency

Cdata isolation

Ddata duplication

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing isolation with redundancy or duplication.

Data isolation allows services to operate independently without interfering with each other's data.

3fill in blank

hard

Fix the error in the statement about microservice data ownership.

Microservices

Microservices should share a [1] to keep data synchronized.

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

Asingle database

Bmessage queue

Ccache layer

Ddistributed ledger

Attempts:

3 left

💡 Hint

Common Mistakes

Assuming shared databases are good for synchronization.

Sharing a single database is an anti-pattern in microservices because it creates tight coupling and reduces service autonomy.

4fill in blank

hard

Fill both blanks to complete the explanation of data ownership benefits.

Microservices

Owning data allows services to [1] independently and [2] failures without affecting others.

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

Adeploy

Bscale

Cisolate

Drecover

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing scaling with deployment or recovery.

Owning data lets services deploy independently and recover from failures without impacting other services.

5fill in blank

hard

Fill all three blanks to complete the microservice data ownership pattern.

Microservices

A microservice owns its [1] to ensure [2], enabling [3] and fault tolerance.

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

Adata

Bautonomy

Cscalability

Dconsistency

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing consistency with autonomy or scalability.

Owning data ensures autonomy, which enables scalability and fault tolerance in microservices.

Practice

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