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

Practice

1. Why are case studies important when learning about microservices design?

easy

A. They show real-world decisions and trade-offs made in actual systems.

B. They provide exact code snippets to copy for your projects.

C. They focus only on theoretical concepts without practical examples.

D. They guarantee the best design for every microservice system.

Solution

1. Step 1: Understand the role of case studies

   Case studies present real examples of how systems were designed and the decisions made.

2. Step 2: Identify the benefit of practical decisions

   They reveal trade-offs and challenges faced, helping learners understand practical impacts.

3. Final Answer:

   They show real-world decisions and trade-offs made in actual systems. -> Option A

4. Quick Check:

   Real-world examples = D [OK]

Hint: Case studies show real decisions, not just theory [OK]

Common Mistakes:

• Thinking case studies only provide code
• Assuming case studies are purely theoretical
• Believing case studies guarantee perfect designs

2. Which of the following best describes a practical decision shown in microservices case studies?

easy

A. Writing all microservices in the same programming language regardless of use.

B. Choosing a database technology based on expected load and data type.

C. Ignoring network latency because it rarely affects microservices.

D. Deploying all services on a single server to reduce costs.

Solution

1. Step 1: Identify practical decisions in case studies

   Case studies often show technology choices based on system needs like load and data.

2. Step 2: Evaluate options for realistic decisions

   Choosing a database based on load and data type is a practical, common decision.

3. Final Answer:

   Choosing a database technology based on expected load and data type. -> Option B

4. Quick Check:

   Tech choice by needs = B [OK]

Hint: Practical decisions match system needs, not assumptions [OK]

Common Mistakes:

• Assuming all services must use same language
• Ignoring network latency effects
• Thinking single server deployment is best practice

3. Consider a case study where a microservice was split into two smaller services to improve scalability. What is the most likely practical reason for this decision?

medium

A. To isolate resource-heavy functions for better scaling.

B. To reduce the total number of services in the system.

C. To make deployment more complex and slower.

D. To combine unrelated functionalities into one service.

Solution

1. Step 1: Understand the goal of splitting services

   Splitting services usually aims to isolate parts that need different scaling or resources.

2. Step 2: Analyze options for scalability improvement

   Isolating resource-heavy functions allows scaling only those parts, improving efficiency.

3. Final Answer:

   To isolate resource-heavy functions for better scaling. -> Option A

4. Quick Check:

   Splitting for scaling = A [OK]

Hint: Split services to isolate heavy workloads [OK]

Common Mistakes:

• Thinking splitting reduces total services
• Believing splitting makes deployment slower intentionally
• Combining unrelated functions is not a splitting reason

4. A case study shows a microservice architecture where services communicate synchronously, causing delays. What practical fix does the case study likely suggest?

medium

A. Combine all services into one to avoid communication.

B. Increase the number of synchronous calls to improve reliability.

C. Ignore delays as they do not affect user experience.

D. Switch to asynchronous communication to reduce waiting times.

Solution

1. Step 1: Identify the problem with synchronous communication

   Synchronous calls cause services to wait, increasing delays and reducing performance.

2. Step 2: Find the practical solution from case studies

   Switching to asynchronous communication allows services to work independently, reducing delays.

3. Final Answer:

   Switch to asynchronous communication to reduce waiting times. -> Option D

4. Quick Check:

   Async communication reduces delays = C [OK]

Hint: Async calls reduce wait times in microservices [OK]

Common Mistakes:

• Increasing synchronous calls worsens delays
• Combining services loses microservices benefits
• Ignoring delays harms user experience

5. A case study describes a microservices system that initially used a shared database for all services but later moved to separate databases per service. What practical reasons does the case study illustrate for this change?

hard

A. To force all services to use the same schema.

B. To make data management more complex and slower.

C. To improve service independence and reduce coupling.

D. To reduce the number of databases to manage.

Solution

1. Step 1: Understand the impact of a shared database

   Shared databases create tight coupling, making services dependent on each other's data schemas.

2. Step 2: Analyze benefits of separate databases per service

   Separate databases improve independence, allowing services to evolve without affecting others.

3. Final Answer:

   To improve service independence and reduce coupling. -> Option C

4. Quick Check:

   Separate DBs reduce coupling = A [OK]

Hint: Separate databases increase service independence [OK]

Common Mistakes:

• Thinking separate DBs increase complexity negatively
• Assuming shared DB forces same schema is good
• Believing separate DBs reduce number of databases