Capstone: E-Commerce Services

Introduction

E-commerce microservices capstone — decompose checkout into catalog, cart, order, payment, inventory, and notification services with gateway, Kafka events, saga, and resilience patterns from this course.

The story

Black Friday load test: monolith p99 checkout 8s. Decomposed architecture — cart in Redis, order saga with orchestrator, payment with circuit breaker, inventory via events — p99 420ms at 5× traffic. One payment outage degraded to "pay later" queue instead of site-wide 503.

The business problem

Teams that skip disciplined E-Commerce Services thinking pay in coupling, outages, and failed microservices interviews:

• Distributed ops: no tracing or health checks — hours to debug one checkout failure.
• Coupling: shared databases and libraries recreate monolith pain across the network.
• Deploy blast radius: one bad service deploy takes down unrelated domains.
• Team boundaries: services aligned to tech layers instead of business capabilities.

The problem teams faced

This lesson addresses:

• When and why E-Commerce Services matters in decomposed architectures.
• How to define service boundaries and contracts under interview time pressure.
• Trade-offs vs alternatives — what staff engineers articulate in architecture reviews.
• Production patterns and failure modes in distributed systems.

Understanding the topic

Core idea: E-Commerce Services in microservices architecture.

• Problem — distributed ops and coupling this topic addresses.
• Service design — boundaries, contracts, and data ownership.
• Trade-offs — sync vs async, consistency, deploy blast radius.
• Interview — how this appears in decomposition loops.

Internal architecture

E-Commerce Services — microservices view:

CDN → API Gateway → BFF
   ↓
Catalog (ES) · Cart (Redis) · Order (Saga orchestrator)
   ↓ sync gRPC          ↓ async Kafka
Payment (CB + adapter) · Inventory · Notification
   ↓ each DB-per-service
Tracing: single checkout trace_id across all hops

Visual explanation

Three diagrams: service architecture, decomposition process, and operational lens:

Informative example

Example — E-Commerce Services:

Checkout saga:
1. Cart → Order: CreatePendingOrder
2. Inventory: ReserveStock (compensate: Release)
3. Payment: Charge (compensate: Refund)
4. Order: Confirm → emit OrderPlaced
5. Notification: async email from event
Idempotency keys on every step

Execution workflow

Real-world use

Netflix pioneered microservices at scale with hundreds of services and chaos engineering. Amazon's two-pizza teams and service-oriented architecture shaped modern decomposition. Uber migrated from monolith to domain-aligned services for independent deploys. Spotify uses squad-aligned microservices with internal platform tooling. These journeys inform every pattern in this course.

Production case study

Black Friday load test: monolith p99 checkout 8s. Decomposed architecture — cart in Redis, order saga with orchestrator, payment with circuit breaker, inventory via events — p99 420ms at 5× traffic. O…

• Context: monolith pain or decomposition scenario from this lesson.
• Decision: service boundary and communication choices explained.
• Outcome: deploy frequency, incident isolation, or latency impact.

Trade-offs

• Pro: team autonomy and isolated failure domains.
• Con: distributed complexity — tracing, sagas, contract tests.
• Con: premature decomposition costs more than a modular monolith.

Decision framework

• Start modular monolith; extract when bounded context and team force are proven.
• Database-per-service — integrate via API and events, not shared schema.
• Document rejected alternatives — ADR or interview closing statement.

Best practices

• Align services to business capabilities, not technical layers.
• Draw sync vs async paths; propagate trace context on every hop.
• Health checks + readiness gates before traffic shift.

Anti-patterns to avoid

• Distributed monolith — shared DB, coupled deploys, synchronous chains everywhere.
• Nano-services — operational overhead exceeds team benefit.
• Shared libraries hiding domain coupling between teams.

Common mistakes

• Splitting before bounded contexts are clear — endless refactor.
• Cross-service transactions without saga or idempotency.

Debugging tips

• Follow one trace_id through the decomposition diagram.
• Ask "what couples these services?" for every sync call.

Optimization strategies

• Replace sync chains with domain events where latency allows.
• BFF to aggregate calls — don't make clients orchestrate services.

Common misconceptions

• Microservices ≠ always better — monolith wins for small teams and unclear domains.
• Interviews test decomposition judgment — not memorizing Netflix's service count.

Advanced interview questions

Summary

You can explain E-Commerce Services in microservices interviews and production RFCs — with bounded contexts, data ownership, and resilience patterns. Teach it back without notes.