E-Commerce Microservices

Overview

This diagram represents a cloud-native e-commerce platform built on AWS using a microservices architecture. Each business capability — users, products, orders, payments, notifications — is deployed as an independent service with its own dedicated data store. This design enables teams to develop, deploy, and scale services independently.

Request Flow

Traffic flows through a layered network stack before reaching the application services:

1. DNS (Route 53) resolves the domain and routes requests to CloudFront (CDN) for edge caching. 2. CloudFront forwards to WAF (Web Application Firewall) for security filtering. 3. Clean traffic reaches ALB (Application Load Balancer) which distributes across targets. 4. API Gateway receives all requests and routes them to the appropriate internal service via gRPC.

This multilayered approach provides defence in depth — each layer adds caching, security, or routing capabilities without coupling to business logic.

Service Decomposition

User Service Handles authentication, authorization, and user profiles. It owns a primary PostgreSQL database with a read replica for scaling read-heavy workloads like profile lookups. This is a common pattern — separate read replicas absorb query traffic without competing with write capacity.

Product Service Manages the catalog and inventory. It stores product data in PostgreSQL, caches frequently accessed data in Redis, writes static assets (images) to S3, and indexes product data in Elasticsearch for full-text search. This showcases the database-per-service pattern where a single service may own multiple storage types for different concerns.

Order Service Orchestrates the order lifecycle — creation, validation, payment processing, and fulfilment. It writes to a sharded DynamoDB table for horizontal scalability and emits Order Events to the Event Bus (Kafka) whenever an order changes state. This decouples order processing from downstream consumers.

Payment Service Processes payments by integrating with external providers (via SendGrid for notifications). It also publishes Payment Events to the event bus. The payment service communicates with the order service over internal protocol for order status updates.

Notification Service Consumes events from the Event Bus and sends emails and push notifications via SendGrid. By subscribing to events rather than being called directly, it can be scaled independently and doesn't block the critical checkout path.

Data Tier

All data services are grouped under a data-tier boundary:

• PostgreSQL: User DB (with read replica), Product DB — relational data with ACID guarantees
• DynamoDB: Order DB (sharded) — NoSQL for horizontal scaling
• Redis: Session cache and shared state across services
• Elasticsearch: Full-text search indexing
• S3: Static asset storage for product images and content
• Kafka: Event bus for asynchronous communication between services

Key Architectural Decisions

• gRPC over REST for inter-service communication — binary protocol with better performance and strong typing via protocol buffers
• Event-driven for order and payment flows — services don't wait for responses from downstream consumers
• Read replicas for read-heavy workloads — keeps the primary database focused on writes
• Sharded DynamoDB for the order service — anticipates high write throughput as the platform scales

Trade-offs

This architecture prioritizes scalability and team autonomy over simplicity. The trade-offs are:

• Operational complexity — running many services requires mature DevOps practices (monitoring, deployment pipelines, incident response)
• Data consistency — eventual consistency across services means the platform must handle scenarios like "order confirmed but payment still processing"
• Network latency — inter-service calls add overhead compared to in-process calls in a monolith

For most early-stage products, a modular monolith is a better starting point. Migrate to microservices when you have clear evidence that team velocity or scalability demands it. This architecture is what a mature, high-traffic e-commerce platform looks like — it's a target state, not a starting point.