E-Commerce Microservices
This example models a production e-commerce backend as a microservices architecture. It covers the order placement flow end-to-end — from the mobile client through the API gateway, across six domain services, and down to the databases and message broker.
System overview
The platform consists of the following components:
| Component | Role |
|---|---|
| Mobile / Browser | End-user client |
| API Gateway | Single entry point, JWT auth, rate limiting, routing |
| Order Service | Creates and manages orders, drives the order saga |
| Inventory Service | Tracks stock levels, processes reservations |
| Payment Service | Charges cards via Stripe, issues refunds |
| Notification Service | Sends emails and SMS via SendGrid and Twilio |
| User Service | Manages accounts, profiles, and authentication tokens |
| Kafka | Asynchronous event bus between services |
| PostgreSQL (per-service) | Each service owns its own database (database-per-service pattern) |
| Redis | Distributed cache for sessions and product catalog |
| Stripe API | External payment processor |
| SendGrid / Twilio | External notification providers |
Architecture decisions
API Gateway as the only entry point
All client traffic enters through the API Gateway. No client has a direct connection to any domain service. This is the Proxy Pattern applied at the ingress level.
The gateway handles:
- JWT validation (delegates to User Service via an internal call)
- Rate limiting (Redis-backed counters)
- Request routing to domain services
- Response aggregation for complex endpoints
Database per service
Each microservice has its own PostgreSQL instance. Services never share a database. Cross-service data access is achieved exclusively through API calls (synchronous) or Kafka events (asynchronous).
Saga orchestration for orders
The Order Service acts as the saga coordinator for the order placement flow. It calls Inventory, Payment, and Shipping in sequence. On any failure, it issues compensating transactions. See Coordinator Pattern.
Kafka for async events
Kafka decouples services that do not need synchronous acknowledgment. The Notification Service consumes order and payment events from Kafka — it is never called directly by Order or Payment service. See Event Bus Pattern.
Animation scenarios
Happy Path — Order Placed
Traces a complete successful order: client authenticates, API gateway routes, Order Service creates the order record, reserves inventory, charges the card, and schedules shipping. Notification Service picks up the event asynchronously from Kafka.
Payment Failure — Saga Compensation
Shows the Order Saga compensating after a card decline: inventory reservation is released, order record is cancelled, and the client receives a 402 response.
Circuit Breaker — Inventory Unavailable
Demonstrates the circuit breaker wrapping the Inventory Service call from the Order Service. After three consecutive timeouts, the circuit opens. Subsequent requests receive an immediate error without hitting the unavailable service.
Cache Hit — Product Catalog
Short scenario showing the API Gateway serving product detail from Redis without hitting the Catalog Service. Demonstrates the read path optimization for high-traffic catalog endpoints.
Edge direction notes
Stripe, SendGrid, and Twilio are external services. Their edges point FROM the internal service TO the external provider — because the internal service opens the HTTPS connection outbound. Never model external SaaS providers as initiating connections inbound.
topology.connect('payment-svc', 'stripe', { protocol: 'https', external: true });
topology.connect('notify-svc', 'sendgrid', { protocol: 'https', external: true });
topology.connect('notify-svc', 'twilio', { protocol: 'https', external: true });Running locally
- Open http://localhost:3000
- Click Examples in the sidebar
- Select E-Commerce Microservices
- Click Run and explore the scenarios in the AnimationPlayer