Aggregates and entities in Microservices - System Design Exercise

Design: Order Management System

Design the domain model focusing on aggregates and entities for order management. Include microservice boundaries and data consistency approach. Out of scope: payment processing, shipping logistics.

Functional Requirements

FR1: Allow customers to create and manage orders

FR2: Each order contains multiple items with quantity and price

FR3: Support updating order status (e.g., pending, shipped, delivered)

FR4: Ensure data consistency within orders and their items

FR5: Allow querying orders by customer and status

Non-Functional Requirements

NFR1: Handle 1000 concurrent order creations per minute

NFR2: API response time p99 < 300ms

NFR3: System availability 99.9%

NFR4: Data consistency within an order must be strong

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Order Service

Order Item Entity

Customer Service (external)

Database with transaction support

API Gateway

Design Patterns

Aggregate pattern for grouping entities

Domain-Driven Design (DDD) principles

Eventual consistency vs strong consistency

Transactional boundaries within aggregates

Reference Architecture

Client
  |
  v
API Gateway
  |
  v
Order Service (Aggregate Root: Order)
  |-- Order Items (Entities)
  |
Database (Transactional)

External Customer Service (for customer data)

Components

Order Service

Spring Boot microservice with REST API

Manages orders as aggregate roots, handles business logic and consistency

Order Item Entity

JPA Entities within Order Service

Represents individual items within an order, part of the aggregate

Database

PostgreSQL with ACID transactions

Stores orders and items ensuring strong consistency within aggregates

API Gateway

Kong or AWS API Gateway

Routes client requests to appropriate microservices

Customer Service

External microservice

Manages customer data, queried by Order Service as needed

Request Flow

1. Client sends create order request to API Gateway

2. API Gateway forwards request to Order Service

3. Order Service validates request and creates Order aggregate with Order Items

4. Order Service saves aggregate in database within a transaction

5. Order Service returns confirmation to client

6. Client queries order status via API Gateway to Order Service

7. Order Service fetches order and items from database and returns data

Database Schema

Entities: - Order (Aggregate Root): order_id (PK), customer_id, status, created_at, updated_at - OrderItem: item_id (PK), order_id (FK), product_id, quantity, price Relationships: - One Order has many OrderItems (1:N) - Order is aggregate root; OrderItems cannot exist without Order - Customer data referenced by customer_id but stored externally

Scaling Discussion

Bottlenecks

Database write contention on orders during high concurrency

Order Service CPU/memory limits under load

API Gateway throughput limits

Solutions

Use database connection pooling and optimize indexes for order queries

Scale Order Service horizontally with stateless instances behind load balancer

Use API Gateway autoscaling and caching for read-heavy endpoints

Interview Tips

Time: 10 minutes for requirements and clarifying questions, 15 minutes for design and data modeling, 10 minutes for scaling and trade-offs discussion

Explain aggregate concept as consistency boundary

Justify why Order is aggregate root and Order Items are entities inside it

Discuss transactional consistency within aggregate

Mention microservice boundaries and external customer service

Describe scaling strategies and bottleneck mitigation