The lens behind every block

Kay Ashaolu — Thu, 18 Jun 2026 16:00:00 +0000

Quick site update before this week's letter: Courses 2, 3, and 4 now have their full written content live. Slide decks, labs, reading material, assessments, and challenges, all in place. The video lectures are still being recorded and will roll out as they finish. If you own any of those courses, log in and the new material is waiting for you.

You can know the seven blocks cold and still design the wrong system. The blocks tell you what to build. They do not tell you why.

The why comes from outside.

Picture a design review. An engineer at the whiteboard has sketched a Service, a Database, a Worker, and a Queue. Each block is correct in isolation. The diagram is clean. The arrows make sense. The review still goes badly.

The senior in the room asks a question the engineer cannot answer. "Who is waiting for this?" The engineer points at the Service. "What if it fails?" The engineer points at the Database. "When does this run?" Long pause.

The blocks were right. The forces behind them were never named. Without the forces, the design is a drawing. A drawing of correct shapes that does not survive contact with the real world.

There are three forces. Every architectural decision you will ever make comes from one of them.

The first is the User. Someone has tapped a button, made a request, opened a page. They are waiting. They do not care that your downstream service is slow or that your database is sharded. They care about three things: the response is fast, it is correct, and it shows up reliably. Every synchronous path in your system exists because of them. The User is why Services exist.

The second is the External Service. Something outside your control that your system depends on. Stripe. SendGrid. OpenAI. Twilio. You did not write their code. You do not own their uptime. Their pager is not your pager. Sooner or later they will fail, time out, throttle you, deprecate the endpoint you depend on, or change the response shape. Your design has to assume this happens. Workers absorb the unreliability. Queues buffer the traffic. Idempotency keys make retries safe. The External Service is why your system has shock absorbers.

The third is Time. The clock. Cron jobs. TTL expirations. Scheduled invoices. The midnight backup. Time does not initiate a request. It fires when it fires. It does not care that the engineering team is in a meeting. It is not waiting for a response. It is simply the heartbeat that triggers work. Time is why Workers run when no User is in sight.

When you look at a system through these three forces, the block selection stops being a debate.

User is waiting? You need a Service. The path must complete in milliseconds and return.

Work has to happen but the User has moved on? You need a Worker, and a Queue feeding it. The User does not stay on the page for the receipt email to send. The receipt email runs in the background.

External Service is unreliable? You need a Worker with retries and a Queue as a buffer. When SendGrid is down at 3 AM, the email is not lost. It sits in your Queue.

Clock fires at midnight? Time pulls a Worker. The Worker rolls invoices, expires sessions, regenerates feeds, takes the backup. No User involved.

The blocks are the answer. The forces are the question.

This is the lens most engineers never get. They learn the technologies. Postgres, Redis, SQS, Kafka. They learn the patterns. Services, queues, workers. They miss that the patterns are responses to something. The system is not a pile of components arranged for elegance. It is a set of decisions about what to do when the three forces show up.

The most common failure mode is to design only for the User. The happy path. The one force you can see. The screenshot in the spec. So the engineer builds a Service and a Database and ships it. Then a third-party API rate-limits them on launch day, and the Service crashes because there is no Worker to absorb the failure. Then the midnight backup fires and there is no Time + Worker arrangement, so it runs inside the same Service as the User requests and slows everything down. Then the engineer rebuilds half the system in production. They blame complexity. The real cause is that they only saw one force.

In Course 1 I teach the three external forces alongside the seven blocks, because the blocks do not mean anything without them. The first thing we do in every design challenge is name the forces. Then we pick blocks. Always in that order. The framework collapses if you skip it.

You do not start a system design with the database. You start with the force asking something of your system.

P.S. There is a full walkthrough of the external forces and how each one pulls different blocks at systemthinkinglab.ai/learn/building-blocks/external-entities/

This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.

System Design at Kekoexchange

Kay Ashaolu — Fri, 13 Sep 2024 12:58:25 +0000

"What's the most important thing for early software engineers to learn in the next five years?"

My answer has recently changed due to the advancements in AI and what seems to be achievable in the near future. With the emergence of tools like GitHub Copilot and Claude, it is very likely that AI will make engineers an order of magnitude . Given this, how can a software engineer maximize their output knowing this trend is on the horizon?

At Kekoexchange, we emphasize the importance of understanding sound system design and having knowledge of the end-to-end system, including how components connect, interact, and operate to create a scalable system. That's why we're excited to announce a collaborative project. This month, the entire community will be working together to describe the design of a fully featured blog application from scratch.

The community has been asked to respond to the following prompt:

Design a scalable and robust blog application that allows users to create, publish, and manage blog posts. The application should support features like user authentication, content management, commenting, and content discovery (e.g., tags, categories, search). The system should be able to handle high traffic and large volumes of content.

Community members, your input is crucial to this project. Each week, you will share your thoughts, and by the week's end, we will consolidate everyone's input using AI into a single system design. This design will then be evaluated by our System Design Evaluator with your contributions playing a significant role in the final analysis.

Provide a score ranging from 200 to 800 points
Provide an overall summary of the application and its performance
Identify the design's strengths and areas for improvement for the user

Stay tuned every Monday in this newsletter to see what the community comes up with and how we do against the System Design Evaluator. Participating in the process will not only contribute to the project but also significantly enhance your system design skills.

If you want to join the conversation and contribute to our community project, check out our website and sign up to join our community! We look forward to seeing you there!

DEV Community: Kay Ashaolu

The lens behind every block

System Design at Kekoexchange