Master System Design Discussions: From Requirements to Scalable Architecture

1. Requirements and Goals

System design discussions usually start with an open‑ended problem. For example, “design Twitter”. The agenda begins with clarifying requirements, which split into functional and non‑functional categories.

Functional requirements

What are we building?

What are the main use cases (posting tweets, following users, etc.)?

Which platforms (desktop, mobile) are targeted?

What does the engineering team look like?

Non‑functional requirements

Consider usability, latency, and consistency; the CAP theorem becomes relevant when scaling distributed systems.

Aim to follow the ACID model in the database: atomicity, consistency, isolation, durability.

Estimate storage and network capacity using metrics such as daily active users and data volume (e.g., 1 GB per day ≈ 10 KB/s).

While non‑functional topics may not always be prioritized, functional requirements are essential before moving on.

2. User Flow and System API

Outline how users interact with the product and the steps they take. Example flow: login → search → view results → contact business → fill form → send message → view messages.

From the flow, derive API calls, each consisting of an action, required parameters, and expected results.

POST tweet (unique_key, tweet_data, location) → returns URL of the new tweet

GET tweet (unique_key, tweet_id) → returns tweet information in JSON

…

3. High‑Level System Design

Typical design considerations include:

Client DNS lookup for IP address.

Load balancer directing traffic to web servers (round‑robin, least connections, etc.).

Web servers connecting to databases or file storage, with a cache in between.

Web servers also calling microservices such as authentication.

Caching static assets and API responses (e.g., Redis, Memcached) using write‑through/write‑back and eviction policies like LRU.

Database choice: SQL (PostgreSQL) for relational queries or NoSQL (DynamoDB) for distributed workloads.

File storage (e.g., Amazon S3) for media assets.

CDN for caching static resources close to users.

Scaling approaches:

Vertical scaling: add more CPU, memory, or indexes.

Horizontal scaling: shard databases by user ID, location, or hash; use master‑slave replication; employ consistent hashing for load distribution.

Example diagrams illustrate these components.

4. Database Schema

Define tables and columns for the Twitter example:

Tweet: tweetID (string), userID (string), latitude (string), longitude (string), createDateTime (string), numOfLikes (int)

User: userID (string), name (string), email (string), dateOfBirth (string), lastLoginDateTime (string)

UserFollow: followerID (string), followeeID (string)

Like: tweetID (string), userID (string)

…

5. Advanced Topics

Security: encryption, input sanitization, parameterized queries, principle of least privilege.

Queues: using message queues (e.g., RabbitMQ) to handle high request volume, with workers consuming from queues.

…

Overall, this guide provides a practical checklist for conducting system‑design interviews, covering key discussion points and fundamental design concepts.