Core Building Blocks of Any System

A team built an internal dashboard for employees. There was one button: “Generate Report.” When a user clicked it, the screen froze. Sometimes it took 12 seconds. Sometimes the request failed completely. The system wasn’t broken. It was badly structured.

Everything, data fetching, processing, file generation, was happening at once. This is what happens when you don’t understand the core building blocks of a system.

Why Every System Looks Different but Works the Same Way

No matter what you build:

• a chat app
• an e-commerce website
• an AI tutor
• a payment system

They are all made from the same basic pieces. If you understand these pieces, you can design any system.

Clients: Where Requests Begin

A client is anything that sends a request.

It could be:

• a web browser
• a mobile app
• another service

The client’s job is simple. It asks for something and waits for a response. Clients should not contain business logic. They should stay light and fast.

APIs: The Door to Your System

The client never talks directly to databases or internal logic.

It talks to an API.

An API defines:

• what requests are allowed
• what data is required
• what responses look like

Think of APIs as contracts. If the contract is clear, systems can change internally without breaking clients.

Services: Where the Work Happens

Services contain business logic.

They:

• validate requests
• apply rules
• coordinate data
• call other services

In small systems, one service may do everything. In larger systems, services are split by responsibility. Good service boundaries make systems easier to scale and fix.

Databases: Where Data Lives

Databases store permanent data. Users, orders, messages, certificates, everything ends up here. Databases are powerful but slow compared to memory. This is why systems avoid hitting the database for every request.

Caches: Making Systems Fast

A cache stores frequently used data in memory. Instead of asking the database again and again, the system checks the cache first.

This:

• reduces load on the database
• improves response time
• increases system stability

Caching is one of the simplest ways to improve performance.

Queues: Doing Work in the Background

Some work does not need to happen immediately. Sending emails. Processing videos. Generating reports.

Queues allow systems to:

• accept requests quickly
• process tasks later
• handle spikes safely

Queues protect your system from sudden overload.

How These Pieces Work Together

A typical flow looks like this:

• The client sends a request to the API.
• The API forwards it to a service.
• The service checks the cache.
• If needed, it reads from the database.
• If background work is required, it pushes a task to a queue.

This pattern appears everywhere.

Once you see it, you’ll recognize it in every system design question.

Sync vs Async Communication

Synchronous communication means:

• The client waits until the work is done.

This is good for:

• login
• fetching data
• simple updates

Asynchronous communication means:
The client does not wait.

This is good for:

• emails
• notifications
• file processing
• AI inference jobs

A common beginner mistake is making everything synchronous.

That leads to slow systems and poor user experience.

Latency, Throughput, and Availability

Latency is how long one request takes.

Throughput is how many requests the system can handle.

Availability is how often the system is up.

You can have:

• low latency but low throughput
• high throughput but poor availability

System design is about balancing these, not maximizing one blindly.

Monolith vs Microservices

A monolith is a single application.

Everything runs together:

• APIs
• logic
• data access

Monoliths are:

• easier to build
• easier to debug
• faster to start with

Microservices split the system into many small services.

They:

• scale independently
• fail independently
• add complexity

Most systems start as monoliths. Microservices are introduced when scale and team size demand it. In interviews, choosing a monolith first is often the right answer.

Key Takeaways

Systems fail not because of bad code, but because of poor structure.

If you understand:

• clients
• APIs
• services
• databases
• caches
• queues

You can design almost anything.