VINAY BHAJANTRI
← SELECTED WORK SYSTEM / CASE STUDY ONLINE
CASE STUDY / Cloud-Native Scaling / E-Commerce

FlashScale

An end-to-end flash-sale system built to validate Kubernetes autoscaling, GitOps delivery, observability, and high-load behavior under production-style traffic.

ENGINEERING SIGNAL / 01

Testing whether a cloud-native delivery system can build, sync, observe, and scale an e-commerce workload under flash-sale traffic.

SOURCE ↗
~/portfolio/flashscale/architecture LIVE SYSTEM MAP
01Application workloadReact / Vite
02CI + image registryJenkins / Docker
03GitOps deliveryGitHub / ArgoCD
04Runtime + autoscalingAWS EKS / ALB
05Load + observabilityLocust / Prometheus
REQUEST→LOGIC→STATE→DELIVERY
STACK /ReactFastAPIDockerAWS EKSKubernetesHPATerraformJenkinsECRArgoCDPrometheusGrafanaLocust
01 / Product Context

Why this system exists.

FlashScale is an e-commerce-at-scale engineering project built around a React/Vite frontend, FastAPI backend, AWS EKS, Jenkins, ECR, ArgoCD, Terraform, Prometheus, Grafana, and Locust. The application gives the infrastructure something real to deploy and stress while the project validates CI/CD, GitOps, blue/green behavior, observability, and horizontal pod autoscaling.

Autoscaling and GitOps are easy to describe on a diagram but harder to prove as a connected system. The goal was to validate the whole path: code becomes an image, deployment state moves through GitOps, Kubernetes runs it behind ingress, monitoring can explain its behavior, and HPA actually reacts when load drives CPU beyond the configured target.

02 / Engineering Role

End-to-end ownership.

I worked across the application and platform path: containerizing the React/FastAPI workload, provisioning AWS/EKS infrastructure with Terraform, creating Jenkins build/deploy automation, integrating ECR and ArgoCD, configuring Kubernetes resources and HPA, deploying Prometheus/Grafana, writing Locust traffic scenarios, and debugging the failures that prevented metrics and scaling from working correctly.

03 / Architecture

The product as connected layers.

01

Application workload

React/Vite provides the storefront while FastAPI exposes product, checkout, order, health, build-info, and metrics behavior used during deployment and load validation.

React · Vite · FastAPI · Docker
02

CI + image registry

Jenkins builds container images and pushes them to Amazon ECR, carrying build/deployment metadata into the release path.

Jenkins · Docker · AWS ECR
03

GitOps delivery

The pipeline updates Kubernetes manifests in Git, and ArgoCD reconciles that desired state into the EKS cluster rather than Jenkins directly becoming the long-term deployment authority.

GitHub · ArgoCD · Kubernetes manifests
04

Runtime + autoscaling

EKS runs the workload behind ingress/ALB. Resource requests and metrics-server allow HPA to scale backend replicas between the configured minimum and maximum under CPU pressure.

AWS EKS · ALB · HPA · Metrics Server
05

Load + observability

Locust generates flash-sale traffic while Prometheus and Grafana expose CPU, memory, replicas, targets, and HPA behavior needed to validate the experiment.

Locust · Prometheus · Grafana
04 / Core Workflows

Where product logic becomes behavior.

01

Code → image → GitOps → cluster

  1. Developer pushes application change
  2. Jenkins builds and pushes image to ECR
  3. Pipeline updates deployment manifest
  4. ArgoCD detects Git desired-state change
  5. EKS reconciles and runs the new version
02

Traffic → CPU → scale-out

  1. Locust ramps traffic through the application
  2. Backend CPU crosses the HPA target
  3. Metrics are supplied to Kubernetes
  4. HPA increases replicas from the minimum toward the configured maximum
  5. Replica count falls again when pressure drops
03

Observe the scaling event

  1. Prometheus scrapes application and cluster metrics
  2. Grafana dashboards visualize CPU and replica movement
  3. kubectl/HPA events confirm rescale decisions
  4. Load-test stats provide the traffic-side evidence
04

Blue / green release validation

  1. Deployment color/version is injected as build metadata
  2. Blue and green versions can be distinguished at runtime
  3. Traffic/version checks verify which release is active
  4. Deployment behavior can be inspected instead of inferred from image tags alone
05 / Engineering Decisions

Not just what was built — why.

DECISION / 01

Use GitOps as the deployment boundary

Jenkins is responsible for building and updating desired state, while ArgoCD performs cluster reconciliation. This separates CI work from continuous deployment and leaves deployment intent visible in Git.

DECISION / 02

Make the deployed version observable

The backend exposes build metadata so blue/green validation can identify the running version and color rather than relying only on pipeline logs.

DECISION / 03

Validate HPA with real resource pressure

CPU requests/limits, metrics-server, Prometheus visibility, and Locust traffic are all required for an HPA claim to be meaningful. The project validates the scaling event under load instead of just committing an HPA YAML file.

DECISION / 04

Treat observability failures as engineering work

Prometheus target discovery, kube-state-metrics ports, Grafana datasource configuration, application metrics, and Kubernetes metrics availability were debugged until the monitoring path could explain the runtime.

06 / Challenges

Complexity designed around.

CHALLENGE / 01

Prometheus targets existed but were DOWN

Kubernetes service discovery and target configuration had to be corrected before cluster and application metrics were trustworthy.

CHALLENGE / 02

HPA could not read resource metrics

Metrics-server and its cluster configuration were missing from the autoscaling path; installing and configuring it restored the metrics HPA depends on.

CHALLENGE / 03

Pods would not scale despite load

HPA needs resource requests to calculate utilization. Adding CPU/memory requests and limits made the percentage-based target meaningful.

CHALLENGE / 04

Monitoring showed no useful application metrics

FastAPI needed explicit Prometheus instrumentation and Grafana needed the correct in-cluster datasource/service configuration before dashboards reflected the workload.

07 / Outcome

What the system supports now.

  • Locust load testing exercised the application up to 5,000 concurrent users in the documented validation runs.
  • Kubernetes HPA was validated scaling backend replicas from 2 to 10 under CPU pressure and scaling down afterward.
  • Jenkins → ECR → Git manifest update → ArgoCD → EKS forms an automated CI/GitOps delivery path.
  • Prometheus and Grafana expose the metrics needed to correlate load, CPU pressure, replica changes, and cluster state.
  • Blue/green build metadata and runtime version checks make release identity visible during deployment validation.

FlashScale is backed by a public GitHub repository. The case study reflects its documented EKS architecture, Jenkins/ArgoCD delivery flow, HPA configuration, Locust validation, monitoring stack, and recorded debugging work.

← BACK TO SELECTED WORK