---
title: "Real-life scenario: MarketBridge"
chapter: "16"
---

# Real-life scenario: MarketBridge

MarketBridge is a global retailer. Its customer channels need fast releases,
but orders must still reach SAP, customer context comes from Salesforce, and
employee changes come from Workday.

## Business requirements

- Checkout availability: 99.95%; product browsing should degrade gracefully.
- Campaign traffic: ten times normal load within ten minutes.
- No order loss; SAP may be slow for hours.
- Production data remains in approved regions.
- RPO: five minutes. RTO: one hour for ordering.
- Teams need independent releases with central security guardrails.
- Measure cost per completed order.

## Proposed architecture

Route 53 directs users to CloudFront. WAF protects public HTTP traffic. An ALB
created by the AWS Load Balancer Controller routes to EKS.

Use one production cluster per active region/account and separate
non-production. Start customer APIs on EKS Auto Mode because they need standard
Kubernetes behavior but no node access. Keep a small managed node group only
if an approved host-level integration agent truly needs it.

Pods use EKS Pod Identity. Checkout writes the order transaction to Aurora and
publishes an event through an outbox pattern. SQS buffers work for the SAP
adapter. Idempotent consumers and a DLQ prevent duplicates and poison messages.
EventBridge distributes business events. Salesforce and Workday adapters have
timeouts, rate limits, retry policies, and private connectivity where supported.

Store images in ECR, scan with Inspector, deploy digests, and enforce Pod
Security plus admission policy. Use default-deny network policy. Secrets live
in Secrets Manager with KMS. Centralize CloudTrail and EKS audit logs.

Spread replicas and compute across three AZs. HPA scales Pods on request and
queue metrics; Auto Mode supplies nodes. Use Spot only for retryable workers.
Protect Aurora with backups and cross-region recovery aligned to RPO/RTO.

## What happens when SAP stops?

Checkout still accepts orders after the durable order commit. SQS depth rises.
Autoscaling is capped to protect SAP. Users see “order received,” not an
endless spinner. Operators get an alert from queue age and error-budget impact.
When SAP returns, idempotent workers drain the queue.

## Decision record

**Decision:** Auto Mode for general workloads, asynchronous ERP integration,
managed databases, and separate regional production clusters.

**Rejected:** one giant global cluster, synchronous SAP calls in checkout,
permanent access keys, and active/active everything without business proof.

## Prove it

Load-test the tenfold campaign, terminate nodes and Pods, simulate AZ and SAP
failure, rotate secrets, roll back a bad image, restore into an isolated
environment, and measure recovery and cost per order.