Hi Curious Heads! π
If you have followed the series, you would have seen how quickly we fall into issues as we scale…
First one thing struggles to keep up, and shortly it is all a forest fire π₯ in our VPCs!
To mitigate this, we need to have an idea of growth rates π and point of failures β to ensure we can scale correctly as per need and not waste our money πΈ to random scaling just to keep things running…
What do we call this step?
Ans: Back-of-the-envelope Estimations π§Ύ
Why?
Because they are so simple π‘ that we can do them on the go β over an envelope βοΈ or even a paper napkin π½οΈ once we’re good enough on our numbers and thinking π―.
Letβs Practice This
Let’s take a simple, well-known app to use as a reference β
YouTube π₯π
π‘ What are we dealing with here?
Entities (oversimplified):
- Users
- Videos
- Comments
Types of Data:
- User Content
- Users Metadata
- Video Metadata
- Comments Metadata
- Global Distribution
- Video Analytics (likes/views/etc.)
π Translate Architecture to Needs
Component | Resource Need |
---|---|
Content Distribution | Network Bandwidth π |
User + Comments + Video Metadata | Database Storage ποΈ |
Videos | Object Storage π¦ |
Now comes the fun part β breaking things down π₯
π§ Memory Estimations (Storage)
User Table
- One record = 40 Bytes
- 1 Million Users β
1,000,000 x 40B = 40,000,000 Bytes β 40MB
User Content
- One record = 80 Bytes
- If each user posts 10 items β
1M x 10 x 80B = 800,000,000 Bytes β 800MB
And we havenβt even included indexing, caching, or relational tables yet!
πΆ Bandwidth Estimations (Traffic)
Letβs assume each video view streams 2MB data on average.
If we have 500K Daily Active Users (DAU), each watching 5 videos/day:
- 500K x 5 x 2MB = 5,000,000 MB = 5 TB/day π³
Thatβs 150 TB/month just in outgoing traffic β and thatβs just views, not uploads!
βοΈ System Load Estimations (Throughput)
- 1M Users β ~500K DAU
- One server can handle 50K concurrent connections
So:
500K / 50K = 10 servers minimum π₯οΈ
Add redundancy, spikes, and background jobs and the number easily doubles.
π― Why It Matters?
These back-of-the-envelope estimations donβt need to be perfect β but they give you a gut-check framework to know whatβs coming your way.
They help you:
- Avoid over-engineering early π οΈ
- Plan for realistic resource costs π΅
- Communicate ideas clearly to teams or stakeholders π§βπ»
Next time you think “Will our system handle this?”,
Donβt panic β pull out that napkin and do the math π―π§Ύ
See you in the next one!
β Anmoldeep π¨βπ»