Skip to content
Krishna Panjiyar
Full-StackInfrastructureBackend

Cloud-Native E-Commerce Platform

Auth, catalog, and order microservices behind GraphQL, deployed on AWS EKS and autoscaling from 3 to 10 pods.

  • React
  • Next.js
  • NestJS
  • GraphQL
  • PostgreSQL
  • Redis
  • Stripe
  • Docker
  • Kubernetes
  • AWS EKS
  • GitHub Actions

The code is not public yet and is available on request. Request the code

Results

  • 3 to 10

    pods, autoscaled on AWS EKS

  • 10K

    transactions/day in load tests

  • 3

    services: auth, catalog, orders

Problem

Build a store that handles sign-in, browsing, and checkout as separate services, so each part can scale and ship on its own, and that stays reliable when traffic grows.

My role

Solo project. I built the auth, catalog, and order services, the GraphQL API layer, the React/Next.js front end, the CI/CD pipeline, and the Kubernetes deployment.

Architecture

Architecture diagram: Services sit behind one GraphQL layer; Redis absorbs repeat reads; EKS scales pods with load.Architecture diagram: Services sit behind one GraphQL layer; Redis absorbs repeat reads; EKS scales pods with load.
Services sit behind one GraphQL layer; Redis absorbs repeat reads; EKS scales pods with load. Open full size (opens in a new tab)Open full size (opens in a new tab)
Diagram source (Mermaid)
flowchart TD
  W["React / Next.js front end"] --> G["GraphQL API"]
  subgraph EKS["AWS EKS: autoscaling 3 to 10 pods"]
    A["Auth service"]
    C["Catalog service"]
    O["Order service"]
  end
  G --> A
  G --> C
  G --> O
  EKS --> R[("Redis cache")]
  EKS --> P[("PostgreSQL")]
  EKS --> S["Stripe payments"]
  GH["GitHub Actions CI/CD"] -->|"build and deploy"| EKS

Key decisions and tradeoffs

Split by business capability
Auth, catalog, and orders change at different rates and see different load. Separate services let catalog reads scale without touching checkout.
One GraphQL layer for the client
The front end asks for exactly the fields a page needs in one request, instead of stitching several REST calls together.
Cache the read-heavy path
Catalog data is read far more than it is written, so Redis serves repeat reads and keeps load off PostgreSQL.
Autoscale instead of over-provisioning
Kubernetes on EKS runs 3 pods at baseline and scales to 10 under load, so capacity follows demand.

What I'd improve next

  • Add distributed tracing across the three services.
  • Record a checkout walkthrough and link it here.