Engineering Notes

00 - E-Commerce Platform - Master

Properties1
tagsarchitecture, ecommerce, interview

2 min read

E-Commerce Platform --- Master

Goal Build a production-style e-commerce backend that

demonstrates the engineering problems commonly discussed in senior backend, architect, and system-design interviews.

What We Are Building

A simplified Amazon-like platform with:

  • Product / Catalog
  • Customer
  • Cart
  • Order
  • Inventory
  • Payment
  • Shipping
  • Notification

The goal is not to reproduce Amazon. The goal is to build enough of a realistic system to discuss scalability, reliability, consistency, observability, security, and failure handling.

Architecture

flowchart LR
    Client["React / API Client"] --> Gateway["API Gateway"]

    Gateway --> Product["Product Service"]
    Gateway --> Cart["Cart Service"]
    Gateway --> Customer["Customer Service"]
    Gateway --> Order["Order Service"]

    Product --> ProductDB[("PostgreSQL")]
    Customer --> CustomerDB[("PostgreSQL")]
    Order --> OrderDB[("PostgreSQL")]
    Cart --> Redis[("Redis")]

    Order --> Outbox[("Transactional Outbox")]
    Outbox --> Kafka["Kafka"]

    Kafka --> Inventory["Inventory Service"]
    Kafka --> Payment["Payment Service"]
    Kafka --> Shipping["Shipping Service"]
    Kafka --> Notification["Notification Service"]

    Inventory --> InventoryDB[("PostgreSQL")]
    Payment --> PaymentDB[("PostgreSQL")]

    Gateway -.-> OTel["OpenTelemetry"]
    Product -.-> OTel
    Order -.-> OTel
    Inventory -.-> OTel
    Payment -.-> OTel

    OTel --> Grafana["Grafana"]
    Product --> ELK["ELK"]
    Order --> ELK

Technology Stack

Area Technology

Backend Java / Spring Boot Backend alternative .NET / ASP.NET Core Database PostgreSQL Messaging Apache Kafka Cache / shared state Redis Containers Docker / Docker Compose AWS locally LocalStack Observability OpenTelemetry + Grafana Logging ELK Cloud AWS Orchestration Kubernetes / EKS API REST + OpenAPI Optional gRPC / GraphQL UI React

Learning Path

Docker
  ↓
Kafka
  ↓
Event-Driven Architecture
  ↓
Database Transactions
  ↓
Transactional Outbox
  ↓
Saga
  ↓
Idempotency
  ↓
CQRS
  ↓
Redis / Caching
  ↓
Resilience
  ↓
Observability
  ↓
AWS / LocalStack
  ↓
Kubernetes

Rule for this project Every technology should solve a real

problem. Do not add a pattern merely because it looks good on a diagram.

Interview Story

The final project should let us answer:

  • Why microservices?
  • Why Kafka?
  • Why PostgreSQL?
  • Why Redis?
  • Why Outbox?
  • Why Saga instead of a distributed transaction?
  • How do we handle duplicate messages?
  • How do we handle retries?
  • What happens when Payment is unavailable?
  • How do we observe a request across services?
  • How do we scale the system?
  • What happens when a service crashes?
  • Why Kubernetes?
  • Why AWS?
  • Why not simply use EC2?
  • [[Docker]]
  • [[Kafka]]
  • [[Event Driven Architecture]]
  • [[Transactional Outbox]]
  • [[Saga Pattern]]
  • [[Idempotency]]
  • [[Caching and Redis]]
  • [[Circuit Breaker]]
  • [[Distributed Tracing]]
  • [[Dependency Injection]]
  • [[CAP Theorem]]
  • [[Kubernetes]]

Graph View