3 Lessons: System Design

The quality of your design is limited by the quality of your understanding of the problem.

Before drawing a single diagram, make sure you know exactly what you're building and why.

2. Start With the End State and Work Backwards

Once the requirements are clear, most people immediately start thinking about inputs, APIs, and services.

I prefer starting at the opposite end.

What does success look like?

Where is the data supposed to end up? Is it powering a user interface? Feeding a dashboard? Stored in a data warehouse? Sent to another service? How is the user supposed to interact with your system?

Your end state defines the system.

Once you understand the destination, the path becomes much easier to reason about. From there, identify the starting state and work backwards until the two connect.

This approach prevents you from exploring dozens of unnecessary design paths. Instead of designing every possible solution, you're designing the solution that gets your data from its starting point to its intended destination.

A well-defined start state and end state turn a messy problem into a solvable one.

3. Start Simple, But Design for Failure

The best system designs are rarely the most complicated ones.

A common trap is overengineering. Engineers often design for problems they don't actually have yet, introducing layers of complexity that make systems harder to build, maintain, and debug.

Start with the simplest design that satisfies your requirements.

Then ask yourself three questions:

• Where are my single points of failure?
• How does the system recover when something breaks?
• Can I observe what's happening when things go wrong?

Failures are inevitable. Services go down. Messages get dropped. Databases become unavailable. The goal isn't to eliminate failures -- it's to design systems that can tolerate them.

Observability is just as important! If you can't trace requests, monitor system health, or understand where failures occur, debugging becomes a nightmare.

A simple system with good observability and fault tolerance is almost always better than a complex system built around hypothetical future requirements.

Build what you need today. Leave room for growth tomorrow.

Final Thoughts

Most system design content focuses on scaling.

Scaling is important, but it's only one piece of the puzzle.

The engineers I've learned the most from spend far less time discussing distributed systems and far more time discussing requirements, tradeoffs, failure modes, and business needs.

Before worrying about how your system will handle millions of users, make sure you understand the problem, define the destination, and build something simple enough to evolve.

Everything else becomes much easier after that.