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.