Introduction to system design

System design is both a technical discipline and a way of thinking. An interview tests whether you can decompose a large problem, identify constraints, and choose tools for explicit reasons.

A YouTube view counter is a useful example. Incrementing a number sounds trivial, but doing it accurately under global load requires a distributed system.

The same reasoning applies outside interviews. It helps teams design systems, write architecture documents, and explain why one solution is preferable to another.

Think of system design as assembling a model from reusable building blocks. Each block is an engineering concept that solves a recurring class of problems.

A building block may describe data storage, communication, partitioning, caching, or failure handling. The concept is reusable, while its implementation depends on the requirements and scale.

The design process has three recurring steps:

1. Decompose the system into smaller problems.
2. Match each problem with suitable building blocks.
3. Compare alternatives by scalability, reliability, latency, and cost.

This is not a fixed recipe. The important skill is understanding why a particular building block fits the current constraints.

System design defines an architecture that provides required features while preserving desired qualities under an expected workload.

The work includes:

• identifying functional and non-functional requirements;
• decomposing a large problem into smaller ones;
• selecting architectural concepts and technologies;
• comparing the trade-offs of alternative solutions.

The goal is not to memorize finished architectures. It is to develop a repeatable reasoning process.

A messaging system is a useful learning model because it exposes fundamental distributed-systems problems early:

• synchronous versus asynchronous communication;
• delivery guarantees and acknowledgements;
• message storage and reprocessing;
• scaling producers and consumers;
• overload and failure handling.

Application A sends a message and application B receives it without depending on the sender's internal implementation.

This simple flow leads naturally to queues, brokers, partitioning, replication, and other architectural decisions.

Different system families solve different parts of the messaging problem:

• Message brokers, such as RabbitMQ and Apache ActiveMQ;
• event streaming platforms, such as Apache Kafka and Amazon Kinesis;
• managed cloud queues, such as Amazon SQS and Azure Queue Storage;
• publish-subscribe systems, such as Amazon SNS and Google Cloud Pub/Sub.

Each family offers different guarantees and trade-offs. The choice should begin with delivery, ordering, throughput, retention, and failure requirements—not with a product name.

The course evolves a system incrementally:

1. State a concrete problem.
2. Consider several possible solutions.
3. Compare how they affect the system's qualities.
4. Add the selected concept to the wider architecture.

This approach reveals recurring problems behind specific technologies: moving, aggregating, storing, and retrieving data while preserving reliability and controlling cost.