The E-Commerce Platform Architecture and Pipeline Topology

The Five Services

Product Catalog

The catalog service is the simplest in the platform. It serves product listings from a PostgreSQL read replica, caches aggressively in Redis, and exposes a REST API consumed by the frontend shell and the checkout service (for price validation).

Property	Value
Repository	`acme/catalog-service`
Runtime	Node.js 20
Data store	PostgreSQL (read replica), Redis (cache)
API surface	REST: `GET /products`, `GET /products/:id`, `GET /search`
Deploy frequency	3-5 times per week
Risk profile	Low. A bad deploy shows stale products. No data loss, no revenue impact.

The catalog pipeline is the simplest: build, test, scan, promote to staging. No special gates beyond the standard security scan. This makes it a good candidate for introducing pipeline concepts before adding complexity.

Inventory

The inventory service tracks stock levels, handles reservations during checkout, and processes restocking events from a warehouse integration. It is write-heavy and race-condition-sensitive. Two concurrent checkout requests for the last unit of a product must not both succeed.

Property	Value
Repository	`acme/inventory-service`
Runtime	Java 21, Spring Boot 3
Data store	PostgreSQL (primary), Redis (distributed locks)
API surface	REST: `POST /reserve`, `POST /release`, `GET /stock/:sku`
Deploy frequency	2-3 times per week
Risk profile	Medium. A bad deploy can oversell inventory. Financial impact, but recoverable with manual order cancellation.

The inventory pipeline adds a database migration gate. Every deployment that includes a schema change must pass a backward-compatibility check (covered in CH9). The Locust scenario for this service simulates concurrent reservation requests to catch race conditions.

Checkout

The checkout service orchestrates the purchase flow. It validates the cart against the catalog, reserves inventory, initiates payment, and creates the order record. It calls three other services synchronously and is the most latency-sensitive path in the platform.

Property	Value
Repository	`acme/checkout-service`
Runtime	Go 1.22
Data store	PostgreSQL (orders), Redis (cart sessions)
API surface	REST: `POST /checkout`, `GET /orders/:id`
Deploy frequency	1-2 times per week
Risk profile	High. A bad deploy means customers cannot complete purchases. Revenue loss is immediate and measurable.

The checkout pipeline is the most complex. It includes contract tests against the catalog, inventory, and payments APIs (covered in CH6). It has the strictest Locust gate: p99 latency must stay below 800ms on the checkout flow with 200 concurrent users. Deployment uses canary with Argo Rollouts and automated rollback.

Payments

The payments service handles payment processor integration, tokenization, and PCI-scoped operations. It has the strictest security requirements and the most restrictive deployment policy.

Property	Value
Repository	`acme/payments-service`
Runtime	Java 21, Spring Boot 3
Data store	PostgreSQL (transactions), Vault (tokenized card data)
API surface	REST: `POST /charge`, `POST /refund`, `GET /transactions/:id`
Deploy frequency	Weekly, with mandatory approval
Risk profile	Critical. A bad deploy can double-charge customers or leak payment data. Financial and regulatory impact.

The payments pipeline adds PCI-specific gates: no secrets in logs, no debug endpoints exposed, mandatory mTLS verification, SAST scan with zero tolerance for injection vulnerabilities. Deployment requires manual approval in the GitHub Actions workflow and a successful canary with a 30-minute bake time.

Frontend Shell

The frontend shell is a server-side rendered application that composes responses from the catalog, inventory, and checkout services. It is the only service that end users interact with directly.

Property	Value
Repository	`acme/frontend-shell`
Runtime	Next.js 14
Data store	Redis (session store)
API surface	HTTP: serves HTML pages, proxies API calls to backend services
Deploy frequency	3-5 times per week
Risk profile	High visibility, medium financial impact. A bad deploy is immediately visible to every user but does not directly cause data loss or payment issues.

The frontend pipeline includes Lighthouse CI as a performance gate (page load time, bundle size) in addition to the standard Locust gate. Deployment uses blue-green with instant traffic switch because partial rollouts on a frontend create inconsistent user experiences.

Inter-Service Dependencies

┌──────────────┐
│ Frontend     │
│ Shell        │
└──┬───┬───┬───┘
   │   │   │
   v   v   v
┌──┴─┐┌┴──┐┌┴───────┐
│Cat-││Inv-││Check-  │
│alog││ent-││out     │
│    ││ory ││        │
└────┘└──┬─┘└┬───┬───┘
         │   │   │
         │   v   v
         │ ┌─┴─┐┌┴───────┐
         │ │Inv-││Payments│
         │ │ent-││        │
         │ │ory ││        │
         │ └────┘└────────┘
         │
         v
    (async: warehouse
     restocking events)

The frontend shell calls catalog, inventory (for stock status display), and checkout. The checkout service calls catalog (price validation), inventory (reservation), and payments (charge). Inventory receives asynchronous restocking events from the warehouse system via a message queue.

This dependency graph matters for deployment ordering. Deploying a breaking change to the inventory API while the checkout service still expects the old contract breaks the checkout flow. Contract tests (CH6) catch this before deployment. Canary deployments (CH8) catch it during deployment.

The Infra Repo in Detail

The ecommerce-infra repository holds every Kubernetes manifest, Helm values file, Kustomize overlay, and ArgoCD application definition for the platform. No Kubernetes resource is applied directly from a service repo. Every change to the cluster state goes through this repo.

ecommerce-infra/
├── base/
│   ├── catalog/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   ├── hpa.yaml
│   │   └── kustomization.yaml
│   ├── inventory/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   ├── hpa.yaml
│   │   ├── pdb.yaml
│   │   └── kustomization.yaml
│   ├── checkout/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   ├── hpa.yaml
│   │   ├── pdb.yaml
│   │   └── kustomization.yaml
│   ├── payments/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   ├── networkpolicy.yaml
│   │   ├── pdb.yaml
│   │   └── kustomization.yaml
│   └── frontend/
│       ├── deployment.yaml
│       ├── service.yaml
│       ├── ingress.yaml
│       ├── hpa.yaml
│       └── kustomization.yaml
├── overlays/
│   ├── staging/
│   │   ├── catalog/
│   │   │   └── kustomization.yaml
│   │   ├── inventory/
│   │   │   └── kustomization.yaml
│   │   ├── checkout/
│   │   │   └── kustomization.yaml
│   │   ├── payments/
│   │   │   └── kustomization.yaml
│   │   └── frontend/
│   │       └── kustomization.yaml
│   └── production/
│       ├── catalog/
│       │   └── kustomization.yaml
│       ├── inventory/
│       │   └── kustomization.yaml
│       ├── checkout/
│       │   └── kustomization.yaml
│       ├── payments/
│       │   └── kustomization.yaml
│       └── frontend/
│           └── kustomization.yaml
└── argocd/
    ├── app-of-apps.yaml
    ├── catalog-staging.yaml
    ├── catalog-production.yaml
    ├── inventory-staging.yaml
    ├── inventory-production.yaml
    ├── checkout-staging.yaml
    ├── checkout-production.yaml
    ├── payments-staging.yaml
    ├── payments-production.yaml
    ├── frontend-staging.yaml
    └── frontend-production.yaml

Base Manifests

The base/ directory contains the canonical Kubernetes resources for each service. These are environment-agnostic: no replica counts, no image tags, no environment-specific configuration. Every resource includes:

namespace (set per overlay)
Labels: app.kubernetes.io/name, app.kubernetes.io/part-of: ecommerce, app.kubernetes.io/managed-by: argocd
Resource requests and limits (defaults in base, overridden per environment)
Readiness and liveness probes

# base/checkout/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout-service
  labels:
    app.kubernetes.io/name: checkout-service
    app.kubernetes.io/part-of: ecommerce
    app.kubernetes.io/managed-by: argocd
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: checkout-service
  template:
    metadata:
      labels:
        app.kubernetes.io/name: checkout-service
        app.kubernetes.io/part-of: ecommerce
    spec:
      containers:
        - name: checkout
          image: ghcr.io/acme/checkout-service
          ports:
            - containerPort: 8080
              protocol: TCP
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: "1"
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 20
          env:
            - name: CATALOG_URL
              value: "http://catalog-service.$(NAMESPACE).svc.cluster.local:8080"
            - name: INVENTORY_URL
              value: "http://inventory-service.$(NAMESPACE).svc.cluster.local:8080"
            - name: PAYMENTS_URL
              value: "http://payments-service.$(NAMESPACE).svc.cluster.local:8080"

Overlays

Each overlay sets the environment-specific values: namespace, replica count, image tag, resource scaling, and any configuration overrides.

# overlays/production/checkout/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: production

resources:
  - ../../../base/checkout

replicas:
  - name: checkout-service
    count: 5

images:
  - name: ghcr.io/acme/checkout-service
    newTag: "a1b2c3d"

patches:
  - target:
      kind: Deployment
      name: checkout-service
    patch: |
      - op: replace
        path: /spec/template/spec/containers/0/resources/requests/cpu
        value: "500m"
      - op: replace
        path: /spec/template/spec/containers/0/resources/requests/memory
        value: "512Mi"
      - op: replace
        path: /spec/template/spec/containers/0/resources/limits/cpu
        value: "2"
      - op: replace
        path: /spec/template/spec/containers/0/resources/limits/memory
        value: "1Gi"

Pipeline Topology by Risk Profile

The five services share a common pipeline structure but differ in gate strictness and deployment strategy:

Service	Security Scan	Contract Tests	Locust Gate	Deployment Strategy	Approval Required
Catalog	Standard	No	p99 < 200ms	Rolling update	No
Inventory	Standard	Yes (checkout)	p99 < 500ms	Canary (10min bake)	No
Checkout	Standard	Yes (catalog, inventory, payments)	p99 < 800ms	Canary (20min bake)	No
Payments	Enhanced + SAST	Yes (checkout)	p99 < 300ms	Canary (30min bake)	Yes
Frontend	Standard + Lighthouse	No	p99 < 1000ms	Blue-green	No

This table is the map. Every chapter that adds a pipeline stage or deployment pattern references it to show where the new concept applies and where it does not.