System Design Basics

Why this matters

You have now practiced the core interview tools: arrays, hashing, graphs, recursion, dynamic programming, greedy choices, and complexity analysis.

System design asks a different question:

Instead of "What function solves this input?" ask: "What service keeps working as users, data, failures, and latency grow?"

For a financial firm, this could mean designing a trade feed, risk dashboard, market-data cache, or order status service. You do not need to be a senior architect yet. Your goal is to explain clear tradeoffs using the same disciplined thinking from earlier lessons.

In this lesson, we will build a beginner-friendly system design loop you can use in interviews.

A simple interview loop

When you hear "Design X," do not jump straight to databases or code.

Use this loop:

1. Clarify requirements — What must the system do?
2. Estimate scale — How many users, requests, records, or events?
3. Define data — What objects exist?
4. Sketch APIs — How does the outside world interact?
5. Choose components — App servers, databases, caches, queues.
6. Discuss tradeoffs — Speed, correctness, cost, simplicity, reliability.

This is similar to the "Interview Thinking Loop" from Introduction to Data Structures: understand the problem before picking the tool.

You are asked: "Design a service that shows a user their latest executed trades."

What is the best first move?

Functional vs non-functional

System design interviews often separate requirements into two buckets.

Functional requirements

What the system does.

Examples: - Users can view their latest trades. - Users can filter by symbol, like AAPL or BTC-USD. - Internal risk tools can read all trades for a desk.

Non-functional requirements

How well the system must behave.

Examples: - Low latency: latest trades should load quickly. - Reliability: do not lose executed trades. - Security: users only see their own data. - Auditability: historical records must be recoverable.

For finance interviews, correctness and auditability often matter as much as speed.

Before choosing databases, caches, or queues, clarify the system's ________.

The basic pieces

Most beginner system designs combine a few familiar building blocks:

Client
  |
  v
API / App Server
  |
  +--> Cache
  |
  +--> Database
  |
  +--> Queue --> Worker

Think of these like larger versions of data structures:

• Database: durable storage, like a persistent table of records.
• Cache: fast lookup, similar in spirit to a hash table from Hashing and Hash Tables.
• Queue: ordered background work, connected to the queue idea from Stacks and Queues.
• Worker: processes tasks outside the request path.

A good design does not use every component. It uses the smallest set that satisfies the requirements.

APIs describe behavior

An API is the contract between the user/client and your system.

For a trade-history service, you might describe endpoints like:

• POST /trades records an executed trade.
• GET /users/{user_id}/trades returns that user's latest trades.

In an interview, you do not need production code first. But a tiny Python sketch can clarify the data shape and behavior.

```python
# Tiny in-memory sketch of a trade-history API.
# This is not a web server; it models the behavior.

trades_by_user = {}


def record_trade(user_id, trade_id, symbol, quantity, price):
    trade = {
        "trade_id": trade_id,
        "symbol": symbol,
        "quantity": quantity,
        "price": price,
    }
    trades_by_user.setdefault(user_id, []).append(trade)
    return trade


def get_latest_trades(user_id, limit=3):
    return trades_by_user.get(user_id, [])[-limit:][::-1]


record_trade("u1", "t100", "AAPL", 10, 190.50)
record_trade("u1", "t101", "MSFT", 5, 420.25)
record_trade("u2", "t200", "TSLA", 2, 175.00)
record_trade("u1", "t102", "AAPL", 7, 191.10)

print("Latest trades for u1:")
for trade in get_latest_trades("u1"):
    print(trade)
```

True or false: Adding a cache always improves a system and should be one of the first components you add.

Scale changes choices

A design for 100 trades per day is different from a design for 100,000 trades per second.

You can make simple estimates:

• How many writes per second?
• How many reads per second?
• How large is each record?
• How much storage per day?

This connects directly to Time and Space Complexity Analysis: you are still asking, "What happens as input grows?" The input is now traffic and data volume.

```python
# Simple capacity estimate for a trade storage service.

trades_per_second = 5000
bytes_per_trade = 300
seconds_per_day = 24 * 60 * 60

trades_per_day = trades_per_second * seconds_per_day
storage_per_day_gb = trades_per_day * bytes_per_trade / (1024 ** 3)

print(f"Trades per day: {trades_per_day:,}")
print(f"Approx storage per day: {storage_per_day_gb:.2f} GB")

# If we keep 7 years for audit/history:
years = 7
storage_7_years_tb = storage_per_day_gb * 365 * years / 1024
print(f"Approx storage for {years} years: {storage_7_years_tb:.2f} TB")
```

There is rarely one perfect answer

System design is about tradeoffs.

Example: latest-trades service

Simple version

Client -> API Server -> Database

Good when: - Traffic is moderate. - Correctness matters more than ultra-low latency. - You want fewer moving parts.

Faster read version

Client -> API Server -> Cache
                    -> Database

Good when: - Many users repeatedly request the same recent data. - Read latency is a major requirement.

But now you must answer: - When does the cache update? - What if cache and database disagree? - Is stale data acceptable?

In finance, "slightly stale" may be fine for a dashboard but unacceptable for order execution or risk limits.

Your beginner system design template

When answering a basic system design question, use this structure:

1. Restate the goal

   • "We need a service for users to view latest executed trades."

2. Clarify requirements

   • Who uses it?
   • How fresh must the data be?
   • How much history is needed?
   • What security or audit rules matter?

3. Estimate scale

   • Reads/sec, writes/sec, record size, retention.

4. Define data and APIs

   • Trade fields, user ID, symbol, timestamp.
   • Read and write endpoints.

5. Sketch components

   • API server, database, maybe cache or queue.

6. Explain tradeoffs

   • Simplicity vs speed.
   • Freshness vs caching.
   • Reliability vs cost.

Next, Mock Interviews will help you practice saying this out loud under interview pressure.