Case Study · 2026
E-Commerce Microservices — AWS DevOps Pipeline
Designing and automating a production-grade cloud-native delivery pipeline for an 11-service Spring Boot platform.
Context
An e-commerce platform built as 11 independent Spring Boot microservices — API Gateway, Auth, Cart, Config Server, Inventory, Order, Payment, Product, Profile, Search and Eureka — needed a delivery pipeline that could build, scan, tag and ship each service independently, then deploy the entire stack reliably to Kubernetes on AWS.
The Problem
Every manual step between merge and deploy is where trust breaks — untested rebuilds, late-caught vulnerabilities, unexplainable rollbacks. The pipeline had to be the guarantee, not a promise.
Process
Matrix-based CI per service
Each microservice builds independently through a GitHub Actions matrix workflow: checkout → Java 17 → Maven build → Docker build — so one service's failure never blocks the other ten, and build feedback stays fast per-service instead of monolithic.
Shift-left security scanning
Trivy scans every image for HIGH and CRITICAL vulnerabilities immediately after build and before it reaches Amazon ECR — vulnerabilities are caught in CI, not discovered in production.
Immutable, traceable artifacts
Every image is tagged with its Git commit SHA before being pushed to a shared ECR repository, so any running container can be traced back to the exact commit that produced it — no "which version is actually deployed?" guesswork.
Deploy the artifact, not a rebuild
The CD workflow triggers on `workflow_run` and pulls the same SHA-tagged image CI already scanned and pushed — a strict Build Once, Deploy Same Artifact strategy that eliminates rebuild drift between what was tested and what runs.
Design Decisions
Build once, deploy everywhere
CD never rebuilds. It reads `github.event.workflow_run.head_sha` and deploys the exact artifact CI already validated — removing an entire class of environment-drift bugs at the source, not through testing harder.
One umbrella chart, two concerns
A single Helm umbrella chart (`ecommerce`) governs application services and infrastructure components together, so the whole stack versions and upgrades as one unit instead of eleven disconnected releases.
Self-hosted runner as the trust boundary
A self-hosted GitHub Actions runner on EC2 — pre-loaded with AWS CLI, kubectl and Helm — is the only path from GitHub to the EKS cluster, keeping cluster credentials off GitHub-hosted infrastructure.
Observability from day one
Prometheus and Grafana are part of the base deployment, not a later add-on — node, pod and workload-level metrics are visible from the first rollout.
Outcome
✦ 11 microservices building, scanning and deploying independently through one pipeline
✦ Full stack — app + infra — deployed via one Helm umbrella chart to Amazon EKS (`e-commerce-prod`, `ap-south-1`, 3 AZs)
✦ Zero rebuild drift between CI-tested and production-running images, enforced structurally by design
Reflection
“"In a multi-service system, the pipeline is the product. If you can't prove which commit is running, you don't have a deployment — you have a guess."”