Key Concepts

Let's talk about key concepts of system design.

Key Concepts in System Design

Before diving into architectures and diagrams, it’s important to understand a few core concepts that appear in almost every system design discussion.
These concepts help you reason about trade-offs, explain decisions clearly, and avoid common misunderstandings.

This document focuses on the most fundamental ones, explained in a simple and human way, with real intuition behind them.


Performance & Scalability

These two terms are often used together, but they describe different problems.

Performance

Performance describes how fast a system is for a given amount of work.

In practice, this means:

  • How quickly a request is processed
  • How responsive the system feels to a single user
  • How long operations take to complete

If a system has a performance problem, it feels slow even when only one user is using it.

Simple intuition

Performance is about speed right now, with the resources you already have.


Latency & Throughput

Latency and throughput are two different ways of measuring how a system behaves under work.

Latency

Latency is how long it takes to get a response.

It answers questions like:

  • How long does a request wait before completing?
  • How fast does the user see a result?

Low latency systems feel responsive and smooth, which is critical for user-facing applications.

Think of latency as waiting time

Latency is the delay between asking for something and getting it back.


Availability & Consistency

In distributed systems, data is often replicated across multiple machines.
This introduces an important trade-off between availability and consistency.

Availability

Availability means the system is accessible and usable, even when failures occur.

A highly available system:

  • Responds to requests even if some nodes are down
  • Minimizes downtime
  • Is often measured as uptime percentage (e.g., 99.9%)
Availability in practice

An available system always gives you a response — even if the data is not perfectly up to date.


Consistency Patterns

Not all systems need the same level of consistency. Different consistency patterns exist to match different requirements.

Strong Consistency

After a write:

  • All subsequent reads immediately reflect the update
  • Data is replicated synchronously

This provides correctness but can reduce availability and increase latency.

Common in: banking systems, inventory management, financial transactions.


Final Thoughts

System design is mostly about trade-offs.
Understanding these concepts helps you explain why you made a decision — not just what you built.

There is no single correct design.
There is only a design that fits the context, constraints, and goals of the system.