Are your designs business-shaped enough?
Learn about some real-life system design stories and how not every struggle is worth it (sometimes it is better if you just give up)
In this digest, several system design articles are told in the form of a storyline. They describe history, how the company started building the service, why, how it worked at the beginning, how it evolved, and how it got to where it is now.
Even for explaining a “simple” topic, such as load balancing algorithms
used storytelling to walk you through all the algorithms through the lens of a small startup. I loved this 😍It made me think that every system design description, blog post, or whitepaper should be written like this. The best designs are the ones strongly driven and shaped by the business constraints. Business constraints come from stories about the business. Perhaps the business needed to support the virality of celebrity posts, which requires a specific design. Or perhaps data access patterns are very much geographically colocated (think Tinder), which opens up doors to some very specific optimisations that do not apply elsewhere.
There are no good designs without a story. It’s the story that drives designs, so why not share stories always?
How Facebook Live Scaled to a Billion Users (13 min)
Facebook’s Live is one of those crazy-scale systems that needs to be designed on a planet-wide scale. This article will walk you through the core components of Facebook Live and how it deals with flaky connections, virality, and unprecedented scale 🌍.
If you are into system design, this single sentence might be enough to get you interested in this one:
When 1.2 billion users might press play, bad architecture can lead to issues.
Audience: Software Engineers
Value: Learn how Facebook designed its live video 🎥
ToT Rating: ⭐⭐
How Load Balancing Algorithms Really Work (6 min)
I loved this short article 😍. It combines some great tech explanations of load balancing algorithms with engaging storytelling through specific use cases. It is a very unique combination that makes the article content more engaging and relatable. Kudos to
👏.
Audience: Software Engineers
Value: Learn about load balancing
ToT Rating: ⭐⭐
Good struggle vs bad struggle (3 min)
Most engineers have managed to achieve success because they learned to persist through doing hard things. It might start with college/university, where you land in the hardest programs and learn to grind through those. Then at work, programming itself is a series of struggles and hard work to get past those struggles (think of all those hours of reading documentation, learning hard concepts, and debugging).
But not all struggles are the same, and not all of them are good for you.
will tell you why in this article.Audience: All professionals
Value: Learn when it is better to give up
ToT Rating: ⭐⭐
Everything Started with the Promise of Loosely Coupled Systems (6 min)
In this one
talks about the pros and cons of event-driven architectures. The usual scenario goes like this: the company adopts a pub-sub solution, everyone starts publishing/consuming events, and before you know it, you end up with a monolith distributed over a queue. This article will give you some good advice on how to avoid this scenario.
The title got me hooked, I looked forward to reading it. However, it felt too much like a bulleted list. I kind of prefer some “color”/narrative even in very tech-heavy articles.
Audience: Software Engineers
Value: Learn when (not) to use event-driven architecture
ToT Rating: ⭐
2025 Guide to Prompt Engineering in your editor for Software Engineers (11 min)
For all of you doing vibe coding/prompt engineering (are these two terms interchangeable now 🤔), this article will aim to multiply your already multiplied productivity.
As if the huge boost you got from agentic coding is not enough by itself 😜
Audience: Software Engineers
Value: Learn how to prompt engineer/vibe code better
ToT Rating: ⭐
Are you still treating your team like a family? (5 min)
When you start with an engineering leadership position, you might fall into a trap of overindexing on not hurting anybody’s feelings or making sure everything is done democratically.
This article will tell you how this can seriously hurt your team and how to avoid it.
Audience: Engineering Managers
Value: Learn how to build high-performing teams
ToT Rating: ⭐
Aaaaaand we are done for today! ✅
See you soon! 🗞️