Loose coupling in Microservices - System Design Exercise

Design: Microservices System with Loose Coupling

Design focuses on service interaction and communication patterns to achieve loose coupling. Does not cover detailed UI or database internal schema.

Functional Requirements

FR1: Services should operate independently without tight dependencies

FR2: Changes in one service should not require changes in others

FR3: Services must communicate asynchronously where possible

FR4: System should handle failures gracefully without cascading

FR5: Support scaling individual services independently

Non-Functional Requirements

NFR1: Support up to 10,000 concurrent users

NFR2: API response latency p99 under 300ms

NFR3: Availability target 99.9% uptime

NFR4: Data consistency can be eventual where applicable

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway or Service Mesh

Message Broker (e.g., Kafka, RabbitMQ)

Service Registry and Discovery

Circuit Breaker and Retry Mechanisms

Load Balancers

Design Patterns

Event-driven architecture

Publish-Subscribe messaging

API Gateway pattern

Circuit Breaker pattern

Bulkhead isolation

Reference Architecture

Client
  |
  v
API Gateway
  |
  +-----------------------------+
  |                             |
Service A <--> Message Broker <--> Service B
  |                             |
Service C                       Service D

Notes:
- Services communicate asynchronously via Message Broker
- API Gateway routes client requests
- Services are independent and discover each other via registry

Components

API Gateway

Nginx or Kong

Routes client requests to appropriate services and handles authentication

Message Broker

Apache Kafka or RabbitMQ

Enables asynchronous communication between services to decouple them

Service Registry

Consul or Eureka

Allows services to discover each other dynamically

Microservices

Spring Boot / Node.js / Go

Independent services each responsible for a business capability

Circuit Breaker

Resilience4j or Hystrix

Prevents cascading failures by stopping calls to failing services

Request Flow

1. 1. Client sends request to API Gateway

2. 2. API Gateway routes request to Service A

3. 3. Service A processes request and publishes event to Message Broker

4. 4. Service B and Service C subscribe to relevant events and process asynchronously

5. 5. Services update their own databases independently

6. 6. If Service B calls Service D synchronously, Circuit Breaker monitors failures

7. 7. Service Registry helps services find each other's endpoints dynamically

Database Schema

Each microservice owns its own database schema to avoid tight coupling. For example: - Service A: Orders table - Service B: Inventory table - Service C: Billing table No shared database to maintain independence and loose coupling.

Scaling Discussion

Bottlenecks

Message Broker can become a single point of failure or bottleneck

API Gateway may become overloaded with traffic

Service Registry availability impacts service discovery

Synchronous calls between services can cause cascading failures

Solutions

Use a distributed, highly available message broker cluster

Scale API Gateway horizontally with load balancing

Deploy multiple instances of Service Registry with health checks

Favor asynchronous communication and implement Circuit Breakers for sync calls

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying questions, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain why loose coupling improves system flexibility and reliability

Discuss asynchronous communication benefits and trade-offs

Highlight use of service registry for dynamic discovery

Describe failure handling with Circuit Breaker pattern

Mention independent data ownership per service to avoid tight coupling

Practice

1. What does loose coupling mean in microservices architecture?

easy

A. Services depend on each other as little as possible

B. Services share the same database directly

C. Services are tightly connected with direct calls

D. Services must be deployed together always

Solution

1. Step 1: Understand the meaning of coupling

   Coupling means how much services rely on each other. Tight coupling means strong dependence.

2. Step 2: Identify loose coupling meaning

   Loose coupling means services depend on each other as little as possible to allow flexibility and easier changes.

3. Final Answer:

   Services depend on each other as little as possible -> Option A

4. Quick Check:

   Loose coupling = minimal service dependency [OK]

Hint: Loose coupling means minimal dependency between services [OK]

Common Mistakes:

• Confusing loose coupling with shared databases
• Thinking tight connections are loose coupling
• Assuming services must deploy together

2. Which of the following is a common way to achieve loose coupling between microservices?

easy

A. Calling services synchronously with blocking

B. Direct database sharing

C. Hardcoding service URLs in code

D. Using message queues or event buses

Solution

1. Step 1: Identify methods for service communication

   Direct database sharing and hardcoding URLs create tight coupling. Synchronous blocking calls also increase dependency.

2. Step 2: Recognize loose coupling techniques

   Message queues or event buses act as intermediaries, decoupling services and allowing asynchronous communication.

3. Final Answer:

   Using message queues or event buses -> Option D

4. Quick Check:

   Loose coupling uses intermediaries like queues [OK]

Hint: Use intermediaries like queues for loose coupling [OK]

Common Mistakes:

• Choosing direct database sharing
• Selecting synchronous blocking calls
• Hardcoding service addresses

3. Consider two microservices communicating via a message queue. If Service A sends 3 messages and Service B processes 2 messages, what happens to the remaining message?

medium

A. It stays in the queue until processed

B. It is lost immediately

C. It causes Service B to crash

D. It is processed twice

Solution

1. Step 1: Understand message queue behavior

   Message queues store messages until consumers process them. Messages are not lost or duplicated by default.

2. Step 2: Analyze the scenario

   Service A sent 3 messages, Service B processed 2, so 1 message remains in the queue waiting for processing.

3. Final Answer:

   It stays in the queue until processed -> Option A

4. Quick Check:

   Unprocessed messages remain in queue [OK]

Hint: Unprocessed messages stay in queue until consumed [OK]

Common Mistakes:

• Assuming messages are lost if not processed immediately
• Thinking messages cause crashes if unprocessed
• Believing messages are processed multiple times by default

4. A developer hardcoded the URL of Service B inside Service A's code for direct calls. What is the main problem with this approach regarding loose coupling?

medium

A. It improves loose coupling by direct communication

B. It makes services independent and scalable

C. It creates tight coupling and reduces flexibility

D. It automatically handles failures gracefully

Solution

1. Step 1: Understand hardcoding impact

   Hardcoding URLs creates a fixed dependency, making it hard to change or replace services.

2. Step 2: Relate to loose coupling principles

   Loose coupling requires minimal direct dependencies; hardcoding violates this by tightly binding services.

3. Final Answer:

   It creates tight coupling and reduces flexibility -> Option C

4. Quick Check:

   Hardcoding URLs = tight coupling [OK]

Hint: Hardcoding URLs causes tight coupling, avoid it [OK]

Common Mistakes:

• Thinking hardcoding improves loose coupling
• Assuming it makes services scalable
• Believing it handles failures automatically

5. You want to design a microservices system that can continue working even if one service fails temporarily. Which design choice best supports loose coupling and fault tolerance?

hard

A. Use synchronous HTTP calls with retries and timeouts

B. Use a message queue to decouple services and allow asynchronous processing

C. Share a single database among all services for consistency

D. Deploy all services on the same server to reduce latency

Solution

1. Step 1: Analyze fault tolerance needs

   To handle temporary failures, services should not block or fail immediately when others are down.

2. Step 2: Evaluate design choices for loose coupling

   Message queues decouple services and allow asynchronous processing, so one service can continue while another recovers.

3. Step 3: Exclude other options

   Synchronous calls block and may fail if the other service is down. Shared databases create tight coupling. Same server deployment risks single point of failure.

4. Final Answer:

   Use a message queue to decouple services and allow asynchronous processing -> Option B

5. Quick Check:

   Message queues enable loose coupling and fault tolerance [OK]

Hint: Message queues enable async, fault-tolerant loose coupling [OK]

Common Mistakes:

• Choosing synchronous calls that block on failure
• Sharing databases causing tight coupling
• Deploying all services on one server risking failure