I’m Expanding Frontend System Design Essentials

When I first launched Frontend System Design Essentials, my goal was simple:

I wanted to make frontend system design more practical.

Not just high-level whiteboard boxes or diagrams.
Not just abstract architecture terms.
Not just “you should think about scale” without showing what that means in code.

I wanted to build something that helps frontend developers understand the real decisions behind frontend systems:

• how to model data

• how to fetch and cache data efficiently

• how to handle pagination (which strategy to choose at cases)

• how to design optimistic UI

• how to think about real-time updates

• how rendering strategies affect user experience

• how performance, accessibility, security, and testing fit into the system

The course is built around a board-style application, so these ideas are not taught as isolated topics. They are connected through the same application as it grows in complexity.

When people ask for “real-world case studies,” it is easy to imagine that the best learning material would come directly from a large production codebase.

But in practice, real-world applications are often not easy to teach from.

A large product usually carries years of product decisions, experiments, integrations, migrations, shortcuts, and technical debt. A 20-year-old product may contain useful patterns, but it may also contain many decisions that only make sense because of its history.

If you could see the actual frontend code behind a large product like Netflix, YouTube, Jira, or Trello, you might not find a clean architecture textbook. You would probably find code written by different people, at different times, under different constraints.

Some parts may be excellent.
Some parts may be outdated.
Some parts may exist only because of internal systems.
Some parts may be full of product-specific edge cases.

There may also be a lot of integration code scattered everywhere: analytics, reporting, experimentation, observability, permissions, internal platform APIs, migration layers, and one-off business logic.

That is real software.

But it is not always the best way to teach.

A better approach is to extract the useful lessons from real systems:

• what patterns worked well

• what trade-offs were made

• what problems kept appearing

• what anti-patterns made the code harder to change

• what ideas are worth applying in a smaller, understandable example

That is what I try to do in this course.

The board application is not meant to be a random clone. It is a teaching environment. It lets us explore real frontend system design problems — data modeling, normalization, caching, optimistic updates, real-time sync, performance, accessibility, and production readiness — without drowning in years of product-specific complexity.

The goal is to make the useful parts of real-world frontend architecture easier to understand, practise, and apply.

After launching the course, I received some encouraging feedback. People liked that it focused on practical frontend system design rather than staying at the abstract level.

I also ran a survey last month to better understand what developers are struggling with and what kind of learning resource would actually help them.

A few themes became clear.

People were interested in frontend system design, large-scale frontend architecture, interview preparation, real-world case studies, and performance.

In the written answers, they mentioned challenges like structuring data fetching, working with large datasets, refactoring old code, making frontend code more maintainable and scalable, and understanding architecture and design patterns.

One answer that stood out to me was about wanting:

“real world applications and not just building random clones.”

That sentence captured the direction I want this course to take.

The course should not only teach individual techniques like pagination, caching, optimistic UI, or real-time updates (although these are the foundation). It should help developers understand how these techniques connect inside a real application.

It should also help them think before coding, reason about trade-offs, and communicate design decisions clearly in interviews or design reviews.

That made me realize the course needed a stronger “thinking layer.”

Not only:

Here is how to implement pagination, caching, optimistic UI, and real-time updates.

But also:

Here is how to approach the problem before choosing a solution.
Here is how to reason about the trade-offs.
Here is how to explain your design clearly.
Here is how to think about production once the feature is shipped.

So I decided to enhance the course with new lessons and exercises.

I’m adding two new modules to the course.

This module focuses on the early part of system design: before components, before APIs, before state management.

It covers:

• how to clarify vague frontend system design requirements

• how to separate functional and non-functional requirements

• how to understand product, user, interaction, and runtime context

• how to make trade-offs explicit

• how to communicate your design in an interview or design review

This is the part that helps developers move from:

“What component should I build?”

to:

“What problem am I solving, what constraints matter, and what design fits this situation?”

I think this is especially important for mid-level frontend developers who want to grow toward senior-level engineering.

At the senior level, people expect you to do more than implement a feature. They expect you to clarify ambiguity, make reasonable assumptions, explain trade-offs, and guide technical decisions.

The second new module focuses on what happens after a feature is built.

A frontend system does not end when the code is merged.

Once it is in production, we need to know:

• Is it working?

• Is it slow?

• Are users failing to complete key actions?

• Can we roll it out safely?

• Can we roll it back if something breaks?

• Do we know where the problem is when users report issues?

So this module will cover:

• frontend observability

• monitoring errors, slow interactions, and failed requests

• feature flags and gradual rollout

• rollback strategy for frontend changes

• debugging production frontend issues with logs, metrics, and user sessions

This is another area that is often missing from frontend courses.

We talk a lot about building features, but less about operating them.

However, in real teams, production readiness is a big part of senior frontend work.

The goal is to make the course more coherent.

If you have already joined the course, you will get these new modules for free.

And if you join before the new modules are released, you will also get the current course plus these updates included.

I’m planning to increase the course price after the new modules are added, because the course will become more complete and more focused on helping frontend developers grow from mid-level implementation to senior-level system design thinking.

But for now, the current price is still available.

You can check out the course here:

Frontend System Design Essentials

No pressure if now is not the right time. I just wanted to share the thinking behind the update before making a broader announcement later.

For me, this is not just about adding more videos.

It is about making the course more useful, more structured, and more aligned with the real struggles developers have when learning frontend system design.

I’ll share more as the new modules take shape.