Why case studies illustrate practical decisions in Microservices - Design It to Understand It

Design: Microservices Practical Decision Case Study

In scope: illustrating practical design decisions in microservices through a case study example. Out of scope: detailed code implementation or unrelated architectural styles.

Functional Requirements

FR1: Demonstrate how real-world constraints influence microservices design choices

FR2: Show trade-offs between scalability, complexity, and maintainability

FR3: Highlight decisions on service boundaries, communication, and data management

FR4: Explain impact of organizational and technical factors on architecture

Non-Functional Requirements

NFR1: Focus on realistic scale: 1000+ concurrent users

NFR2: Latency target: p99 API response under 300ms

NFR3: Availability target: 99.9% uptime

NFR4: Use common technologies and patterns in microservices

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway

Service Registry and Discovery

Individual Microservices

Message Broker for async communication

Centralized Logging and Monitoring

Database per service

Design Patterns

Database per service pattern

Circuit breaker pattern

Event-driven architecture

API Gateway pattern

Saga pattern for distributed transactions

Reference Architecture

Client
  |
API Gateway
  |
+-----------------------------+
|       Service Registry       |
+-----------------------------+
  |           |           |
Service A   Service B   Service C
  |           |           |
DB A        DB B        DB C
  |
Message Broker (async events)
  |
Monitoring & Logging System

Components

API Gateway

Nginx or Kong

Single entry point for clients, routing requests to appropriate microservices, handling authentication and rate limiting

Service Registry

Consul or Eureka

Keeps track of available microservices and their network locations for dynamic discovery

Microservices

Spring Boot / Node.js / Go

Independent deployable units handling specific business capabilities with own database

Message Broker

Kafka or RabbitMQ

Enables asynchronous communication and event-driven workflows between services

Databases

PostgreSQL / MongoDB

Each service owns its database to ensure loose coupling and data encapsulation

Monitoring & Logging

Prometheus, Grafana, ELK Stack

Collects metrics and logs for observability and troubleshooting

Request Flow

1. Client sends request to API Gateway

2. API Gateway authenticates and routes request to appropriate microservice

3. Microservice processes request using its own database

4. If needed, microservice publishes event to Message Broker for other services

5. Other microservices consume events asynchronously and update their state

6. API Gateway returns response to client

7. Monitoring system collects metrics and logs from all components

Database Schema

Entities are split per microservice. For example, Service A manages 'Orders' entity with fields (order_id, user_id, status, total). Service B manages 'Inventory' entity with (item_id, quantity, location). Relationships between entities across services are handled via events, not direct foreign keys.

Scaling Discussion

Bottlenecks

API Gateway becoming a single point of failure or bottleneck

Service Registry overload with many services

Database contention in high write scenarios

Message Broker saturation with high event volume

Monitoring system overwhelmed by large data volume

Solutions

Use multiple API Gateway instances with load balancing and failover

Partition or shard Service Registry or use highly available solutions

Implement database sharding or use scalable NoSQL stores

Scale Message Broker clusters horizontally and tune partitions

Aggregate and sample monitoring data, use scalable storage backends

Interview Tips

Time: Spend first 10 minutes clarifying requirements and constraints, next 20 minutes designing architecture and explaining decisions, last 15 minutes discussing scaling and trade-offs.

Explain how real-world constraints shape microservices boundaries

Discuss trade-offs between consistency and availability

Highlight importance of asynchronous communication for decoupling

Mention observability as key for operating microservices

Show awareness of scaling challenges and mitigation strategies