Amazon Frugal Architecture Explained 💰
#56: And How to Properly Scale Your Business (5 Minutes)
Get my system design playbook for FREE on newsletter signup:
I’m writing you this letter because cost is often ignored during system design.
Yet I think good architectural decisions should always consider costs.
Otherwise even a business with a solid tech stack would fail.
Share this post & I'll send you some rewards for the referrals.
This post outlines Amazon’s frugal architecture principles via a hypothetical case study. You will find references at the bottom of this page if you want to go deeper.
Once upon a time, there lived 2 software engineers.
They worked for a tech company - Hooli.
Although they were smart, they never got promoted.
So they were sad and frustrated.
Until one day when they had a wild idea to build a startup.
And posted about it on social media to find potential users - positive results.
They created the app prototype based on their assumptions from intense brainstorming sessions.
Yet there was a business risk due to high costs.
So they used Amazon’s frugal architecture as guiding principles.
This Post Summary - Instagram
I wrote a summary of this post:
(Save it for later.)
And I’d love to connect if you’re on Instagram:
Frugal Architecture
Here’s how:
1. The 80-20 Rule
Their minimum viable product (MVP) became expensive from feature creep.
Feature creep occurs when extra features are added to the product than necessary.
So they did user surveys to find the essential features. (Also asked the right questions using the mom test.)
And delivered only the necessary features to reduce costs.
The bottom line: consider cost as a non-functional requirement in system design. (It’ll improve system efficiency.)
2. Scaling Without Breaking
They added servers as the app became popular.
But infrastructure costs skyrocketed as more users joined.
And profit per user went down.
This could destroy their business.
So they set up autoscaling. It automatically scales up and down the infrastructure based on traffic. Thus reducing infrastructure and operational costs.
Imagine autoscaling as getting extra chairs when more people want to sit. And putting those chairs away when they leave.
Also they archived inactive data to save storage costs.
And set up rate-limiting to avoid unnecessary traffic.
The bottom line: architect the system so costs align with the business model.
3. You Can’t Control What You Don’t Measure
Their operational costs were still high.
So they set up monitoring for important metrics.
And tracked resource usage + errors.
It let them:
Find wasteful practices
Assign resources based on priorities
Avoid unnecessary costs quickly
Besides they found bottlenecks in the workflows and automated the solution.
The bottom line: set up monitoring to avoid unknown costs.
4. Every Decision Is a Tradeoff
They set up the database index to improve read performance.
Think of the database index as the table of contents for a database table.
Yet their growth rate was mind-boggling.
And their data layer wasn't stable.
So they added database read replicas to route the read traffic there.
Imagine the database read replica as the copy of a book so more people can read it at once without waiting.
The bottom line: know the tradeoffs of each architectural decision.
5. Divide and Conquer
They added features as time passed.
But managing many features at a high scale became expensive.
So they categorized services based on importance.
And implemented granular controls for different components.
The non-critical features got scaled down.
While unused features were removed.
It lets them reduce costs.
The bottom line: (1) build the app with tunable building blocks. (2) rank the services based on importance. (3) optimize important services.
6. It’s a Marathon, Not a Sprint
The media content on their app received more traffic than before. (videos and so on.)
Yet the storage and streaming costs were high.
So they stored compressed media files in an object storage.
And set up the content delivery network (CDN) for low latency.
Imagine CDN as the McDonald's fast food chain, you don't go to the main office to buy a burger. Instead nearest branch to save time.
The bottom line: (1) observe patterns. (2) optimize the system periodically.
7. We’ve Always Done It This Way
Their core microservices received extreme requests during peak traffic.
Yet most of their services were written in Ruby.
And the result? Bad performance.
So they built prototypes in different programming languages & profiled the performance.
Then rewrote code in Rust for 50x better performance. (Proof: Ranking programming languages by energy efficiency white paper.)
The bottom line: (1) question your assumptions. (2) pick the right tool for the job.
While they lived happily ever after.
Apollo 11 - mission to the moon used a guidance computer with only 4 KB RAM and 32 KB storage.
While mobile phones these days offer 8 GB RAM and 64 GB storage.
So it’s not just about minimizing costs but maximizing value. Put simply, frugality leads to innovation.
The bottom line: (1) don’t ignore costs during system design. (2) set limitations on resources - time, money, CPU, and so on.
Join to get simplified case studies delivered straight to your inbox:
Thank you for supporting this newsletter. Consider sharing this post with your friends and get rewards. Y’all are the best.
Good System Design also saves and makes money because it allows you to understand the cost/value trade-offs.
Excellent article, Neo!