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