Lesson 11.2 — How to Approach and Design Any System

In the previous lesson, we established what System Design is and why it matters. Now comes the most pivotal real-world question:

“When assigned to design a brand-new system from scratch—whether in a production architectural review or a senior engineering interview—where do we actually begin?”

Most novice engineers fall headfirst into the Technology-First Trap. The moment they are handed a prompt, their minds race through an index of trendy tools:

Senior Principal Architects never begin this way. Their foundational axiom is simple:

Today, we will dissect the complete step-by-step thinking process using a tangible, real-world case study: “Design an On-Demand Food Delivery Platform (e.g., DoorDash, Uber Eats, or Foodpanda).”

The prompt “Build a food delivery app” is catastrophically ambiguous. Jumping straight to sketching server diagrams is equivalent to building a foundation without knowing whether you are erecting a garden shed or a 50-story commercial tower.

Your first responsibility is to eliminate ambiguity by asking scoping questions:

Next, we explicitly enumerate: “What discrete capabilities must the system perform?”

Our food delivery system involves three primary human actors:

Now we define the operational boundaries and performance constraints under stress:

Engineering without estimation is guesswork. We do not need high-precision decimals; we need rough order-of-magnitude calculations to drive our structural decisions:

Notice the power of this calculation: before doing math, you might have imagined needing a massive 50-node Cassandra cluster. Back-of-the-envelope math proved that your primary challenge is not storage capacity, but peak connection handling and memory caching.

Before writing code or configuring infrastructure, you must model the fundamental entities that form your system's data plane:

Clients interact with your backend via explicit interface contracts. Defining RESTful endpoints enforces clear separation between client presentations and domain business logic:

With our requirements, estimates, and data contracts established, we sketch our high-level architecture:

               [ Mobile Customers ]        [ Restaurant Portals ]        [ Courier Riders ]
                        │                          │                           │
                        └──────────────────────────┼───────────────────────────┘
                                                   ▼
                                      [ API Gateway / Reverse Proxy ]
                                                   │
                                                   ▼
                                    [ Food Delivery App Servers ]
                                                   │
                        ┌──────────────────────────┴──────────────────────────┐
                        ▼                                                     ▼
             [ PostgreSQL Database ]                                 [ External Services ]
        (Users, Orders, Menus, Payments)                           (Stripe, bKash, Maps API)
        

Now we possess a structural skeleton. The architect's true work begins: “Where will this break under real-world traffic?”

We systematically pressure-test every node:

One of the most transformative architectural skills is recognizing what work must complete synchronously versus what work can be safely deferred asynchronously.

When a customer taps “Place Order”, they need immediate confirmation that their payment cleared and their order was recorded:

In distributed systems, failures are not rare anomalies; they are normal operational occurrences:

“Assume everything will fail. Anything that can fail, will eventually fail in production.”

Deploying without telemetry leaves your team flying blind during an outage:

Navigate the 12-step blueprint, simulate real-world capacity estimates with dynamic math, and contrast synchronous vs. asynchronous execution latency.