01 Architecture
Distributed execution via AWS EKS
The platform runs 8 independent microservices built in Go, Java, and Node.js. Inbound traffic is handled by an API Gateway written in Go, deployed directly onto an AWS Elastic Kubernetes Service (EKS) cluster.
DOCUMENTED02 Failure Isolation
Preventing cascading outages
Services are connected with RabbitMQ for asynchronous, event-driven communication. If a downstream service (e.g., inventory processing) crashes, the message queue acts as a shock absorber. The checkout service remains online, capturing orders and queuing them until the inventory service recovers.
03 Infrastructure as Code
Reusable Terraform Modules
The entire underlying infrastructure—VPCs, subnets, EKS clusters, and node groups—is codified using Terraform. By creating reusable modules with remote state stored in S3, spinning up identical staging and production environments is completely automated.
04 Security Boundaries
Cluster security operates on a zero-trust model. Kubernetes NetworkPolicies block all pod-to-pod traffic by default, explicitly allowing only necessary communication paths. Furthermore, AWS IAM Roles for Service Accounts (IRSA) was implemented so pods authenticate directly with AWS services, eliminating hardcoded passwords or access keys within the cluster.
DOCUMENTED05 Scaling
To protect against database exhaustion during heavy read traffic, Redis caching was implemented to store frequently accessed product data. At the container level, Kubernetes Horizontal Pod Autoscaling (HPA) automatically provisions additional pods dynamically based on CPU/Memory thresholds.
06 Observability
A distributed system without tracing is a black box. Prometheus and Grafana handle metrics collection, while Jaeger provides distributed tracing. This allows engineers to follow a single HTTP request as it jumps asynchronously between all 8 microservices, heavily reducing Mean Time To Detect (MTTD).
07 Engineering Decisions
RabbitMQ architecture
Service-to-service messaging and failure isolation. RabbitMQ was used to connect the independent microservices, with the architecture designed so a failure in one service would not take the rest of the store offline.
Kafka may become more attractive under different throughput, replay, retention, or event-streaming requirements. RabbitMQ is excellent for complex routing topologies and traditional work queues, but lacks the immutable log durability of Kafka at massive scale.
08 Results & Evidence
45m → 15m
AWS environment provisioning
Measurement
Environment: Not recorded in the current source material.
Condition: Not recorded.
Method: Not recorded.
Runs: Not recorded.
Scope
Included: VPC, EKS cluster provisioning
Excluded: Not specified.
Constraints: None documented.
Interpretation
Reusable Terraform modules reduced the stated AWS setup time from 45 minutes to 15 minutes.
Application startup performance, Production incident recovery time
Engineering Decision
Choice: Reusable Terraform modules with S3-backed state
Alternatives considered: Not recorded.
Retrospective: Not recorded.
<10m
Failure Detection
Measurement
Environment: Not recorded in the current source material.
Condition: Not recorded.
Method: Not recorded.
Runs: Not recorded.
Scope
Included: Prometheus, Grafana, Jaeger
Excluded: Not specified.
Constraints: None documented.
Interpretation
Observability stack enables rapid identification of broken services.
Automated remediation time
Engineering Decision
Choice: Full-stack observability with distributed tracing
Alternatives considered: Not recorded.
Retrospective: Not recorded.
09 Limitations
Architectural Constraints
- 01 —RabbitMQ Bottlenecks
While it provides excellent failure isolation, a central message broker can become a single point of failure itself. Running it in a highly available cluster is mandatory for production.
- 02 —Observability Overhead
Jaeger tracing is incredibly useful, but instrumenting 8 microservices across 3 different languages (Go, Java, Node.js) requires significant developer discipline to ensure trace context is passed correctly.