Why good service boundaries prevent coupling in Microservices - Design It to Understand It

Design: Microservices with Good Service Boundaries

Focus on defining service boundaries and their impact on coupling. Out of scope are specific implementation details of each microservice.

Functional Requirements

FR1: Each microservice should have a clear, focused responsibility.

FR2: Services should communicate with minimal dependencies.

FR3: Changes in one service should not require changes in others.

FR4: The system should allow independent deployment of services.

Non-Functional Requirements

NFR1: Services must maintain loose coupling to enable scalability.

NFR2: Latency between services should be minimized but can tolerate small delays.

NFR3: Availability target is 99.9% uptime for the overall system.

NFR4: Services should be independently scalable.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

Key Components

API Gateway or Service Mesh for communication

Service Registry for discovery

Database per service pattern

Event-driven messaging for asynchronous communication

Design Patterns

Single Responsibility Principle for services

Database per service to avoid shared databases

Event-driven architecture to decouple services

Anti-corruption layer to isolate legacy systems

Reference Architecture

Service A

↓

Service B

↓

Service C

Components

API Gateway

Nginx or Kong

Single entry point routing requests to appropriate services

Service A

Node.js microservice

Handles specific business capability A with its own database

Service B

Spring Boot microservice

Handles business capability B independently

Service C

Python Flask microservice

Handles business capability C independently

Event Bus

Kafka or RabbitMQ

Enables asynchronous communication and decoupling

Databases

PostgreSQL per service

Each service owns its data to prevent coupling

Request Flow

1. Client sends request to API Gateway.

2. API Gateway routes request to the responsible service based on URL or headers.

3. Service processes request using its own database.

4. If needed, service publishes events to Event Bus for other services.

5. Other services subscribe to relevant events and update their state asynchronously.

6. Client receives response from the service via API Gateway.

Database Schema

Each service has its own database schema focused on its domain: - Service A: EntityA (id, attributes) - Service B: EntityB (id, attributes) - Service C: EntityC (id, attributes) No shared tables or cross-service foreign keys to avoid tight coupling.

Scaling Discussion

Bottlenecks

Tight coupling due to shared databases or APIs causing cascading failures.

Synchronous communication causing latency and blocking.

Difficulty deploying services independently due to dependencies.

Data consistency challenges across services.

Solutions

Enforce database per service to isolate data ownership.

Use asynchronous messaging to reduce blocking and coupling.

Define clear service contracts and version APIs carefully.

Implement eventual consistency with event-driven updates.

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying boundaries, 20 minutes designing the architecture and explaining service boundaries, 10 minutes discussing scaling and coupling prevention.

Explain how clear service boundaries reduce dependencies.

Describe how database per service prevents data coupling.

Discuss synchronous vs asynchronous communication impact on coupling.

Highlight benefits of independent deployment and scalability.

Mention patterns like event-driven architecture to maintain loose coupling.

Practice

1. Why do good service boundaries help prevent tight coupling in microservices?

easy

A. They keep services independent by limiting direct data sharing.

B. They force all services to share the same database.

C. They require services to be written in the same programming language.

D. They make services depend on each other's internal code.

Solution

1. Step 1: Understand service independence

   Good service boundaries mean each service manages its own data and logic without relying on others internally.

2. Step 2: Recognize coupling causes

   Tight coupling happens when services share data directly or depend on each other's internal code, which good boundaries avoid.

3. Final Answer:

   They keep services independent by limiting direct data sharing. -> Option A

4. Quick Check:

   Service independence = prevents tight coupling [OK]

Hint: Good boundaries mean no direct data sharing between services [OK]

Common Mistakes:

• Thinking services must share the same database
• Believing services must use the same language
• Assuming internal code sharing is allowed

2. Which of the following is the correct way for microservices to communicate to avoid tight coupling?

easy

A. Directly accessing each other's databases

B. Using well-defined APIs for communication

C. Sharing internal code libraries

D. Calling private functions inside other services

Solution

1. Step 1: Identify communication methods

   Microservices should communicate through clear, public interfaces like APIs, not by accessing internals.

2. Step 2: Evaluate options

   Only using well-defined APIs ensures loose coupling and clear contracts between services.

3. Final Answer:

   Using well-defined APIs for communication -> Option B

4. Quick Check:

   API communication = avoids tight coupling [OK]

Hint: Use APIs, not direct database or code access [OK]

Common Mistakes:

• Choosing direct database access
• Thinking code sharing is good
• Calling private functions across services

3. Consider two microservices: OrderService and InventoryService. If OrderService directly queries InventoryService's database to check stock, what is the likely outcome?

medium

A. Tight coupling occurs, making changes risky and complex.

B. The services communicate through APIs efficiently.

C. The system automatically scales better.

D. Services remain loosely coupled and easy to update.

Solution

1. Step 1: Analyze direct database access impact

   When one service accesses another's database, it creates a strong dependency on internal data structure.

2. Step 2: Understand coupling consequences

   This tight coupling makes updates risky because changes in one service's database can break the other.

3. Final Answer:

   Tight coupling occurs, making changes risky and complex. -> Option A

4. Quick Check:

   Direct DB access = tight coupling [OK]

Hint: Direct DB access causes tight coupling and risks [OK]

Common Mistakes:

• Assuming direct DB access improves scaling
• Believing services stay loosely coupled
• Confusing API communication with direct DB queries

4. A team notices their microservices are tightly coupled because they share a common database schema. What is the best way to fix this issue?

medium

A. Keep sharing the database but add more indexes.

B. Merge all services into one monolithic application.

C. Allow services to call each other's internal functions.

D. Split the shared database into separate databases per service.

Solution

1. Step 1: Identify the cause of tight coupling

   Sharing a database schema tightly couples services because they depend on the same data structure.

2. Step 2: Choose the best fix

   Splitting the database per service enforces boundaries and independence, reducing coupling.

3. Final Answer:

   Split the shared database into separate databases per service. -> Option D

4. Quick Check:

   Separate databases = better service boundaries [OK]

Hint: Separate databases per service reduce coupling [OK]

Common Mistakes:

• Merging services increases coupling
• Calling internal functions breaks boundaries
• Adding indexes doesn't fix coupling

5. You are designing a microservices system for an online store. To prevent tight coupling, which approach best defines service boundaries?

hard

A. Services share internal code libraries to reuse logic.

B. All services share a single database to simplify data access.

C. Each service owns its data and exposes only APIs; no direct data sharing.

D. Services call each other's private methods for faster communication.

Solution

1. Step 1: Define good service boundaries

   Good boundaries mean each service manages its own data and communicates only through APIs.

2. Step 2: Evaluate options for coupling

   Sharing databases or internal code increases coupling; calling private methods breaks encapsulation.

3. Final Answer:

   Each service owns its data and exposes only APIs; no direct data sharing. -> Option C

4. Quick Check:

   Own data + APIs = loose coupling [OK]

Hint: Own data + APIs = best boundaries [OK]

Common Mistakes:

• Sharing a single database
• Reusing internal code across services
• Calling private methods between services