Architecting Atlas How To Handle The Immense Traffic of a
summary
Wakeup migrates its storefront to Atlas on EKS and measures real outcomes: campaign traffic jumps from ~0.6M to 1.8M hits, later a 71% higher peak than a previous launch, and home/product pages collapse under backend requests. Autoscaling with Kubernetes cluster-autoscaler proves too slow (node ready ~5–6 minutes), so Carpenter 60–90s node provisioning (AWS claims 15s) replaces it; pod scaling adds KEDA with Prometheus metrics + a turbo multiplier tested via Artillery (prime-number workload ramp to ~240k) and managed with ArgoCD application sets and replica limits.
AI-written summary · about
chapters (20)
- 0:00Atlas platform intro
- 1:43Handling Wacomp traffic
- 4:53Mayushka campaign disaster
- 7:02First launch failure
- 11:24Campaigns DDoS ourselves
- 12:50Bottlenecks and load testing
- 14:13Need new auto-scaling
- 15:58Introducing Atlas platform
- 17:44Karpenter for node scaling
- 19:10Keda for pod scaling
- 21:34Turbo scaling experiments
- 24:49Scaling strategies analysis
- 25:11Atlas conclusions and future
- 26:25Q&A technical
- 29:56Legacy systems impact
- 31:41Scaling still needed
- 33:27Kubernetes vs Fargate
- 34:32Mayushka campaigns status
- 36:19Q&A architecture
- 38:46Final Q&A scaling
related talks
32mScaling Kubernetes Application to 1M Users
27mRails Orbiting the cloud: Mastering the scalability with Kubernetes
47mPostmortem: A Modern Approach to Managing Kubernetes Clusters
31mSaving Money Exposed Our Architecture - Escaping ClusterAPI with Karpenter
30mPut the ‘Auto’ in Autoscaling — Erwin Daria
27mHarness the power of Karpenter to scale, optimize & upgrade K8s
36mGroupless Autoscaling with Karpenter
32mOptimizing Resource Usage in Kubernetes