A System Design Workshop Without a Single Slide

Many of my friends know that I've recently run several in-person System Design workshops. The original motivation for creating this workshop was System Design interviews.

Anyone who conducts technical interviews can hardly avoid this stage.

The interviewer gives you a problem: design a URL shortener, design a chat system, design a ticketing platform. Then, within forty to fifty minutes, you start from requirements and build the entire system step by step.

There is certainly a lot to talk about here.

Requirement clarification, capacity estimation, database, cache, message queue, scalability, consistency...

If you list all these knowledge points, three hours can easily be filled.

But once I actually started preparing, I discovered a problem:

This knowledge doesn't seem hard to find.

Want to know what scenarios Redis suits? There is plenty of material online. Want to know how Kafka works? There are books, videos, and articles. Want to compare SQL and NoSQL? A quick search yields dozens of answers. Now it's even simpler—just ask an AI.

If my workshop merely reorganizes all this and spends three hours lecturing, it wouldn't be very meaningful.

This made me rethink:

What exactly makes System Design difficult?

---

I've seen this many times. Cache—known. Message Queue—known. Sharding—known. CAP—can even explain it fluently.

But given an unfamiliar System Design problem, they still don't know where to start. The issue isn't a lack of knowledge points; it's that the knowledge in their heads is still scattered.

Real-world problems don't tell us:

You should use a Cache here.

Nor do they jump out at the right moment to remind you:

Now is the time to discuss Data Consistency.

We are given only a problem. Everything else requires our own judgment.

What to think about first? What doesn't matter right now? When should we start considering performance? Why do we need a Cache here? What happens after adding the Cache? When a new problem emerges, do we solve it now or set it aside?

When actually doing System Design, we are constantly making these choices.

So, what makes System Design truly difficult is not how much you know, but whether you can connect what you know.

From Cache to Data Consistency

There is a very simple example in the workshop.

Many performance optimizations essentially come down to trading time and space. Trading space for time is one of the most common.

Most programmers know this concept.

If I wanted to explain the idea of trading space for time, two minutes would be enough:

To improve read speed, you can store redundant data. With redundant data, you need to consider data consistency.

But I didn't present it that way on site.

We started with a question:

What if reads are slow right now?

People began suggesting ideas. Can we precompute? Can we add a Cache? Can we store an extra copy of data better suited for reads?

Gradually, we arrived at the same place:

Trade space for time.

I drew it out and then asked:

How is the system different from before?

We introduced something new. More importantly, data that used to exist in only one place now exists in two.

So what next?

How should the data flow actually work? If one copy changes, when does the other change? What if an update fails halfway? If the two copies differ, which one is correct?

Only then did I write down:

Data Consistency

This is a completely different learning process from being told upfront, "When using redundant data, pay attention to consistency." The former is a piece of knowledge. The latter is a path you have walked.

We didn't start discussing Consistency because the next item on the syllabus said Consistency.

We did because:

We just made a choice, and that choice brought a new problem to the surface.

This is what I truly hope people take away.

In the future, it may not be a Cache. It could be replicas, search indexes, materialized views, or simply storing an extra copy of data somewhere else for query convenience.

Technical terms may change. But whenever the same fact begins to exist in two places, someone should think:

What if they become inconsistent?

Once this connection is established, knowledge starts to become your own.

Good Content Is Cut, Not Added

This was the most obvious change during preparation.

At first, I always felt three hours wasn't enough. This should be covered, that is also important, and all the concepts frequently asked in System Design interviews should be included.

After thinking it through, I started cutting.

Because the more you cover, the more people tend to feel: I learned a lot today. But "learned a lot" and "can use it myself next time" are not the same thing.

I began to care more about other questions:

Can people see the relationships between these pieces of knowledge? After making a choice, can they think of the next question to ask? Faced with a problem they've never seen before, can they find a starting point?

So the workshop's focus gradually shifted from "what do I want to teach" to "what do I hope people will be able to do in the end."

After cutting down, I asked myself:

If all technical details were removed, what would remain of this workshop?

What survives is the true core. In the end, what remained was a very simple path:

First clarify the problem, identify the real constraints, make choices, understand the trade-offs, and then articulate your reasoning clearly.

Cache, Database, Message Queue may all change. But this path will not.

From that point on, the entire design direction of the workshop changed completely.

But there was still one problem.

Even if I figured out how System Design should be approached, standing in front and explaining the whole method doesn't mean others will get it.

If for three hours I am the one thinking, analyzing, and providing answers, listeners can easily develop the illusion that they understand. But when they face a problem themselves, they may still not know what to do next.

So the workshop's question changed again.

Not just:

What should I teach?

But:

In three hours, how can I keep everyone focused while ensuring they actually think through these problems themselves?

This question ultimately determined the entire format of the workshop.

Three Hours: What Is Everyone Doing?

Three hours is really long.

Especially on a weekend.

Just imagining someone standing in front of me talking nonstop for three hours makes it hard for me to maintain attention.

So what I started designing was not three hours of slides, but:

What is everyone doing during these three hours?

Sometimes listening to me, sometimes looking at the posters on the wall, sometimes answering questions, sometimes discussing together, sometimes watching me write down what was just discussed on the whiteboard, and sometimes I deliberately pause and don't give the answer.

Finally, everyone works on a real case together.

I want people's state to keep changing. Listen for a while. Think for a while. Speak for a while. Then continue. Not remain in a "receiving" state for three hours straight.

I told everyone: no need to take notes.

I will share the complete transcript and all hand-drawn materials after the workshop. So there is no need to busy yourself writing things down during these three hours.

Just focus on listening, thinking, and participating.

At this point, slides had become rather unimportant.

I felt that hand-drawn paper was more suitable.

I prepared some large handwritten posters in advance, usually key structures and summaries. As the course progressed, I revealed them one by one and stuck them on the wall.

They don't disappear when you flip a page. When we get to later parts, the content from the first hour or two is still on the wall. I can point back to it at any time, and everyone can see it too.

Here are a few examples.

But there were other things I didn't want to reveal in advance.

Because if the answer is already on the wall, the question becomes meaningless.

So for those parts, I wrote on the spot.

A keyword. A box. A line.

Write as we discuss.

Those posters were indeed liked by many people.

But if I had to choose, I think the most important part of this workshop was not the hand-drawn materials.

It was questioning.

I kept asking.

Why? What would happen if we did this? Are there other approaches? What problem does this solution solve? What is the cost? What if traffic increases tenfold? What if this feature isn't that important after all?

Often, I already knew what I was going to talk about next.

But I would first ask:

What do you think?

Before the answer appears, everyone needs to make at least one judgment of their own.

Whether that judgment is correct doesn't matter.

What matters is that those few seconds belong to each person's own thinking.

The third module of the workshop is a real case.

In the first two modules, I mostly controlled the pace. In this module, we reasoned together.

I presented requirements, and everyone kept asking questions and discussing, then we moved forward based on the answers at each step.

I really liked this part because:

People began to know what questions they should ask.

They began to know how to make choices, how to make judgments, and how to articulate their reasoning clearly.

This may be more important than remembering any specific answer.

Before I Knew It, Nearly Four Hours Had Passed

Clearly, I still have room for improvement in time management.

The first two modules each took about an hour. There was a fifteen-minute break in between. The third module generated so much discussion that I could only quickly skim through the fourth module.

By the time everything ended, it was close to four hours.

But one thing made me quite satisfied.

Throughout the entire process, no one looked at their phone.

And toward the end, people didn't become quieter.

Later, a friend told me:

"A lot of this feels like something I can use at work next week."

Another person said directly:

"Next time you offer a class, I'll sign up immediately."

One friend had never written a line of code.

She was a bit nervous before coming, unsure whether a System Design workshop would be too technical. After it ended, she sent me a long message of feedback.

One line said:

"I could feel everyone's minds following closely. For the entire three hours, I listened with complete focus. I can't remember the last time I concentrated for that long."

She also said she thought not only programmers should attend, but also people in product, data analysis, and even those who want to start a business.

I was very happy when I saw that.

Especially the line "I can't remember the last time I concentrated for that long." Because it exactly answered the question I had been thinking about:

Can everyone stay engaged for three hours?

At least this time, yes.

It also validated an idea I had when designing the workshop: someone who has never written code can understand System Design.

If the workshop content were about how to configure Redis, what parameters Kafka has, or how to shard a database, then people without a technical background would have no reason to attend.

But what we actually spent time discussing was: What exactly is the problem? Why make this choice? What does it solve? What does it introduce? If conditions change, does the previous answer still hold? Is there a simpler way? When should we stop and not continue designing?

These questions certainly appear in System Design.

But they don't belong only to System Design.

You encounter them in product work.

You encounter them in data work.

You encounter them in running a business.

This is also where my understanding of System Design itself changed after preparing this workshop.

Previously, it was easy to interpret it as:

Designing a technical system.

Now I prefer to see it as:

Facing a complex problem and making well-grounded choices step by step.

Technology is just the context this workshop uses to practice these choices.

A person who has never written code could understand it not because I made the content shallow, but because beneath the technical layer, what we were really discussing was how to ask questions, how to make choices, how to weigh trade-offs, and how to articulate your reasoning clearly.

These things never belonged only to technology.

This Workshop Was Also a System Design

I didn't first decide on a technology and then look for a problem it could solve.

Instead, I first thought clearly:

What do I really hope people will learn?

Then I decided:

How can I help people truly learn it?

Cutting content, changing format, removing slides, adding more questioning, redesigning the rhythm—every decision was not made to be "different," but to answer the same question.

So the absence of slides was not a feature I designed from the start.

It was simply that, along the way, slides didn't survive. Questioning survived, discussion survived, paper and pen survived, the real case survived, and the transcript survived.

Next time, you only need to bring paper and a pen. Let's learn System Design together.