Delivery Framework

Requirements (5 mins)

Functional requirements

Lead with

• "Users/clients should be able to …"
• "If system does X, what happened with Y?"

Example:

1. Twitter
   • User should be able to post tweets
   • User should be able to follow others
   • User should be able to see tweets from users they follow
2. Cache:
   • Clients should be able to insert items
   • Client should be able to set expiration
   • Clients should be able to read items

Non-functional requirements

Lead with:

• "System should be able to…"
• "System should be…"

Example:

• System should be highly available, prioitising availability > consistency
• System should be support 100M+ DAU (Daily active user)
• System should be low latency, rendering under 200ms

1. CAP theorem: system needs to choose and prioritise consistency or availability
   • In a system design, partition is given
2. Environment constraints: Any constraint in the environment? ie:
   • Running on limited cpu hardware, network etc
3. Scalability
   • Any unique scaling requirements? does it have bursty traffic at time of day?
   • Event like holidays, will cause system increase the traffic?
4. Latency:
   • How quickly does system respond to users requests?
5. Durability:
   • How important is the data in your system is not lost?
   • i.e Socail network may be able to tolerate some data loss, Banking system cannot
6. Security:
   • How secure system needs to be? Access control, compilation
7. Fault tolerance:
   • How well does the system handle failures? Consider rendundancy, failover and recovery mechanism
8. Compliance:
   • Any legal regulatory requirements system needs to meet? Industry standard, data protection laws.

Capacity estimation

Back-of-envelop estimation only do it when necessary. Most of the time we do it and just say "ok, got it". There is no gain in here. Also do Learn how to estimate quantities quickly

When reaches to here, explain that: "You would like to skip on estimations upfront and will do the math while designing when necessary"

Core Entities (2 mins)

Take a moment and list the core identities of your system. This helps to understand the foundation to build on top. But don't list all

For example, Twitter we might have sometime like:

1. User
2. Tweet
3. Follow

Couple of useful questions?

1. Who are the actors in the system? Are they overlapping?
2. What are the nouns or resources necessary to satisfy the functional requirements?

API or system interface (5 mins)

Before getting to the actual design, list out the API structure

Some options for protocol:

1. REST: HTTP verbs (GET, POST, PUT, DELETE) to perform CRUD on resources. This should be default choice for most interview
2. GraphQL: Allow clients to specify what data they want to receive to avoid over-fetch and under-fetching, choose when you have client with different data need.
3. RPC: Action-oriented protocol like gRPC is faster than REST for service-to-service communication. Use for internal APIs when performance is critical.

Don't overthink this, default to REST unless you have specific reason not to. For real-time features, we can leverage WebSocket or Server-Sent Events (SSE)

For example, in Twitters, we choose REST and have something like this:

POST /v1/tweets
body: {
  "text": string
}

GET /v1/tweets/{tweetId} -> Tweet

POST /v1/follows
body: {
  "followee_id": string
}

GET /v1/feed -> Tweet[]

[!NOTE]
When there is something like UserId related, always authenticate the request and derive from the auth token, not user input

(Optional) Data flow

Some backend system, especially data processing. It can be helpful to describe the high level sequence of actions that the system performs first. For example, for a web crawler we can do something like

1. Fetch seed URLs
2. Parse HTML
3. Extract URLs
4. Store data
5. Repeat

High level design (10-15 minutes)

Primary goal:

1. Satisfy the API
2. Satisfy the requirements

[!danger]
It's very common for candidates to layering complexity too early and never arrive at a complete solution. Focus on simple design that meet core functional requirements first. Then lyaer on complexity to satisfy non-functional requirements in the deep-dive sections. It's natural to add complexity like caches or messages queues while in high level design.

For complexity add-ons, just add a note so that we can go through later and move on.

Walkthrough verbally how the data flow in each stage, each request, starting from the API ending with the response.

• When your request reaches database or persistence layer, start documenting relevant columns,fields for each entity.You can do this directly next to your database visually.

[!danger]
Don't waste your time documenting every column/field in your schema. For example, your interviewer knows that a User table has a name, email, and password hash so you don't need to write these down. Instead, focus on the columns/fields that are particularly relevant to your design.

For example, the twitter one

Deep dive

This is the time we:

1. ensure the system meets all non-functional requirements
2. Addressing edge cases
3. Identify and address issues and bottlenecks
4. Improve the design based on probes from your interviewer

The degree which you're proactive in leading deep dives determine your level of seniority. Most senior candidate should be able to identify these places themselves and lead discussion

For example, Twitter non-functional requirement is scale to > 100M DAU. We could lead to horizontal sacling, database sharding.

In the case of low latency feed, we can lead to fanout-on-read vs fanout-on-write and caching.

[!danger]
A common mistake candidates make is that they try to talk over their interviewer here. There is a lot to talk about, sure, and for senior candidates being proactive is important, however, it's a balance. Make sure you give your interviewer room to ask questions and probe your design. Chances are they have specific signals they want to get from you and you're going to miss it if you're too busy talking