AWS architecture notes
I write about AWS architecture from the inside out: what a request actually touches, how each component behaves under load, where it breaks, and which trade-offs a design is quietly making. Diagrams first, then the reasoning behind them.
Architecture analysis
The same task-management API built twice: Lambda and DynamoDB, then containerised microservices on ECS Fargate with RDS PostgreSQL. I trace a POST /tasks request through each, follow both designs from 10 to 10,000 requests per second, and compare them on cost, scaling, reliability, security and operational load.
Every design is explained by following a real request from the browser to the data store and back — not by listing services.
No architecture is best in general. The useful question is which constraints a design accepts, and whether the workload can live with them.
Prices and quotas change. Where I use numbers they are stated assumptions for reasoning — not figures presented as AWS facts.
