Bird
Raised Fist0
Microservicessystem_design~25 mins

First microservice architecture diagram in Microservices - System Design Exercise

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Design: Simple E-commerce Microservice System
Design microservices for product catalog, order management, and user management. Include API gateway and database. Exclude payment gateway and shipping services.
Functional Requirements
FR1: Users can browse products
FR2: Users can place orders
FR3: Orders are processed asynchronously
FR4: System should handle 1000 concurrent users
FR5: API response time p99 under 300ms
Non-Functional Requirements
NFR1: Availability 99.9% uptime
NFR2: Scale to 1000 concurrent users
NFR3: Latency p99 < 300ms for API calls
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
❓ Question 5
Key Components
API Gateway
Product Service
Order Service
User Service
Database per service
Message Queue for async processing
Design Patterns
API Gateway pattern
Database per service pattern
Event-driven architecture
Circuit breaker for fault tolerance
Reference Architecture
          +-------------+          
          |   Clients   |          
          +------+-----+          
                 |                
          +------+-----+          
          | API Gateway |          
          +------+-----+          
           /     |     \          
          /      |      \         
+---------+  +---+----+  +-------+
| Product |  | Order  |  | User  |
| Service |  | Service|  | Service|
+----+----+  +---+----+  +---+---+
     |           |          |     
+----v----+  +---v----+  +--v----+
|ProductDB|  |OrderDB |  |UserDB |
+---------+  +--------+  +-------+
           \          /          
            +--------+           
            | Message |           
            | Queue   |           
            +--------+
Components
API Gateway
Nginx or Kong
Single entry point for clients, routes requests to appropriate microservices, handles authentication
Product Service
Node.js or Spring Boot
Manages product catalog and product data
Order Service
Node.js or Spring Boot
Handles order placement and processing asynchronously
User Service
Node.js or Spring Boot
Manages user profiles and authentication
Databases
PostgreSQL or MongoDB
Each service has its own database to ensure loose coupling
Message Queue
RabbitMQ or Kafka
Enables asynchronous communication between services, especially for order processing
Request Flow
1. Client sends request to API Gateway
2. API Gateway authenticates and routes request to appropriate microservice
3. Product Service fetches product data from its database and returns to client
4. When user places an order, API Gateway routes request to Order Service
5. Order Service saves order in its database and publishes order event to Message Queue
6. Order processing workers consume events from Message Queue to process orders asynchronously
7. User Service manages user data and authentication independently
Database Schema
Entities: - Product: id (PK), name, description, price, stock - Order: id (PK), user_id (FK), product_id (FK), quantity, status, created_at - User: id (PK), username, email, password_hash Relationships: - Order references User and Product by foreign keys - Each service owns its own database schema to avoid tight coupling
Scaling Discussion
Bottlenecks
API Gateway can become a single point of failure
Order Service database can become a bottleneck under high write load
Message Queue can be overwhelmed with too many events
Product Service database read load can increase with many users browsing
Solutions
Deploy multiple API Gateway instances behind a load balancer for high availability
Use database sharding or read replicas for Order Service database
Scale Message Queue cluster horizontally and partition topics
Implement caching (e.g., Redis) for Product Service to reduce database reads
Interview Tips
Time: 10 minutes for requirements and clarifications, 20 minutes for architecture design and data flow, 10 minutes for scaling discussion, 5 minutes for questions
Explain why microservices are chosen for modularity and scalability
Describe how API Gateway simplifies client interaction
Discuss asynchronous processing with message queue for order handling
Highlight database per service to reduce coupling
Address scaling challenges and solutions clearly

Practice

(1/5)
1. What is the main role of an API Gateway in a microservice architecture?
easy
A. It stores all the data for the microservices.
B. It routes client requests to the correct microservice.
C. It runs the user interface of the application.
D. It replaces all microservices with a single service.

Solution

  1. Step 1: Understand the API Gateway function

    The API Gateway acts as a single entry point that directs client requests to the appropriate microservice.

  2. Step 2: Compare other options

    Storing data is done by individual services, not the gateway. The UI runs separately, and the gateway does not replace microservices.

  3. Final Answer:

    It routes client requests to the correct microservice. -> Option B

  4. Quick Check:

    API Gateway = Request Router [OK]
Hint: API Gateway directs requests, it does not store data [OK]
Common Mistakes:
  • Thinking API Gateway stores data
  • Confusing API Gateway with UI component
  • Assuming API Gateway replaces microservices
2. Which of the following correctly shows a microservice owning its own data?
easy
A. Multiple microservices share one database directly.
B. Microservices do not use databases at all.
C. Each microservice has its own separate database.
D. All microservices write to a single shared file.

Solution

  1. Step 1: Recall microservice data ownership principle

    Each microservice should own and manage its own database to avoid tight coupling.

  2. Step 2: Evaluate options

    Sharing one database or file breaks independence. Not using databases is unrealistic for data needs.

  3. Final Answer:

    Each microservice has its own separate database. -> Option C

  4. Quick Check:

    Microservice = Own Data Store [OK]
Hint: Microservices keep data separate, no shared DB [OK]
Common Mistakes:
  • Assuming all services share one database
  • Thinking microservices don't need databases
  • Using shared files for data storage
3. Given this simple microservice setup:
Client -> API Gateway -> Service A -> Service B
What happens if Service B is down when Client sends a request?
medium
A. The API Gateway automatically retries Service B until it responds.
B. The API Gateway routes the request to Service B's backup automatically.
C. The client request is handled fully by Service A without contacting Service B.
D. Service A will fail to complete the request and return an error to the client.

Solution

  1. Step 1: Trace request flow with Service B down

    The client request goes through API Gateway to Service A, which calls Service B. If Service B is down, Service A cannot complete its task.

  2. Step 2: Understand failure impact

    Without Service B responding, Service A returns an error back through the API Gateway to the client.

  3. Final Answer:

    Service A will fail to complete the request and return an error to the client. -> Option D

  4. Quick Check:

    Down service causes error response [OK]
Hint: Down service causes error, no automatic retry [OK]
Common Mistakes:
  • Assuming automatic retries by API Gateway
  • Thinking Service A can handle request alone
  • Believing API Gateway has backup routing
4. In this microservice diagram, the API Gateway calls Service A and Service B directly. But Service A calls Service B internally and Service B calls Service A internally.
What is the main problem with this design?
medium
A. It creates a circular dependency between services.
B. API Gateway should not call any services directly.
C. Services should share one database instead.
D. Service A should call Service B, not the other way.

Solution

  1. Step 1: Identify service call relationships

    API Gateway calls both Service A and Service B, and Service A calls Service B and Service B calls Service A, forming a loop.

  2. Step 2: Understand circular dependency issues

    Circular dependencies cause tight coupling and can lead to failures or deadlocks.

  3. Final Answer:

    It creates a circular dependency between services. -> Option A

  4. Quick Check:

    Circular calls = Bad design [OK]
Hint: Avoid circular calls between microservices [OK]
Common Mistakes:
  • Thinking API Gateway shouldn't call services
  • Believing shared database fixes call loops
  • Assuming call direction must be reversed
5. You want to design a microservice architecture for an online store with these needs:
- User service manages user profiles
- Product service manages product info
- Order service creates orders and needs user and product data

Which architecture diagram best fits these requirements?
hard
A. Client -> API Gateway -> User Service, Product Service, Order Service; Order Service calls User and Product Services internally.
B. Client -> API Gateway -> Order Service only; Order Service manages users and products internally.
C. Client -> API Gateway -> User Service and Product Service only; Order Service is part of API Gateway.
D. Client -> API Gateway -> User Service; Product Service calls Order Service; Order Service calls User Service.

Solution

  1. Step 1: Analyze service responsibilities

    User and Product services manage their own data. Order service needs to create orders using data from both.

  2. Step 2: Check communication flow

    Order service calling User and Product services internally keeps responsibilities clear and allows data ownership.

  3. Step 3: Evaluate options

    Client -> API Gateway -> User Service, Product Service, Order Service; Order Service calls User and Product Services internally. matches this design. Others either merge services incorrectly or create wrong call flows.

  4. Final Answer:

    Client -> API Gateway -> User Service, Product Service, Order Service; Order Service calls User and Product Services internally. -> Option A

  5. Quick Check:

    Order service calls needed services [OK]
Hint: Order service calls user and product services internally [OK]
Common Mistakes:
  • Merging all logic into one service
  • Placing order service inside API Gateway
  • Incorrect service call directions