Software Engineering Roadmap

Learn how to build, test, deploy, and maintain robust software systems.

Overall Progress0%

System Architecture

Explanation

System architecture is the high-level design of a system: what the major components are, what each is responsible for, how they communicate, and how they are deployed. Good architecture is not about drawing impressive boxes — it is about making deliberate trade-offs that satisfy the system’s requirements for availability, latency, scalability, and reliability. This lesson introduces monoliths and microservices, load balancing, caching, queues, database scaling, and the CAP theorem. It ends with a worked example — designing a URL shortener — so you can see the design process end to end. The most important skill is asking "what are the requirements and what are the trade-offs?", not memorizing architecture names.

What Is System Architecture?

Major components and their responsibilities.
How components communicate.
How data flows through the system.
Deployment boundaries.

Requirements First

	Functional	Non-functional
Question	What must it do?	How well must it do it?
Examples	Create a short URL	Availability, latency, scale, security

A Typical Architecture

Client

↓

Load Balancer

↓

Application servers

↓

Cache

↓

Database

Monolith

A single deployable application.
Advantages: simple deployment, easier local development, fewer network boundaries.
Tradeoffs: scaling is all-or-nothing; the codebase can grow large and coupled.

Microservices

Multiple independently deployable services.
Advantages: independent deployment, per-service scaling, team boundaries.
Tradeoffs: distributed-system complexity, network failures, observability, deployment complexity.

Monolith vs Microservices

	Monolith	Microservices
Deployment	One unit	Many independent units
Scaling	Whole app	Per service
Complexity	In the codebase	In the network
Best for	Small teams, early stage	Large teams, independent domains

Load Balancing

Client

↓

Load Balancer

↓

Server A · Server B · Server C

A load balancer distributes requests across servers, spreading load and improving availability.

Caching

Request

↓

Cache

↓

Hit (return fast)

↓

Miss → Database

A cache stores frequently read data so most requests are answered quickly without hitting the database. The hard part is keeping the cache from serving stale data (invalidation).

Queues and Asynchronous Processing

Producer

↓

Queue

↓

Worker

Useful for email, notifications, background jobs, media processing.
Decouples the request from the work.

Synchronous vs Asynchronous

	Synchronous	Asynchronous
Flow	Caller waits for the result	Caller continues; result arrives later
Latency	Tied to the slowest step	Decouples slow work
Example	A normal API call	A queued email job

Database Scaling

Read replicas: copies that serve reads, offloading the primary.
Sharding/partitioning: splitting data across databases.

The CAP Theorem

CAP states that a distributed system cannot simultaneously guarantee Consistency (all nodes see the same data), Availability (every request gets a response), and Partition tolerance (the system keeps working even when the network between nodes fails).

Availability, Latency, and Scalability

Term	Meaning
Availability	The system is up and responding
Latency	How long one operation takes
Scalability	How well it handles growth

Reliability and Observability

Reliability: timeouts, retries, idempotency, and circuit breakers keep failures contained.
Observability: logs, metrics, and traces give you visibility into a distributed system.

The Design Process

Clarify requirements.
Estimate scale.
Define the API and data.
Choose components.
Identify bottlenecks and trade-offs.

Worked Example: A URL Shortener

A URL shortener turns a long URL into a short code, stores the mapping, and redirects when the code is requested.

Client submits a long URL; the API generates a short code and stores the mapping.
When a code is requested, the API looks it up.
The cache answers hot codes quickly.
The database stores the durable mapping.

Common Architecture Mistakes

Choosing microservices too early.
Skipping requirements.
Ignoring failure modes.
No caching or observability.
Ignoring data consistency.
Assuming unlimited resources.

Examples

A URL-shortener request flow

Trace one redirect end to end.

text

1Client → API (lookup code) → Cache hit → 302 redirect to the long URL

Output

(a cache miss falls through to the database)

Key Takeaways

Architecture is the high-level design of components and their communication.
Start from requirements, especially non-functional ones.
Monoliths are simpler; microservices trade code complexity for operational complexity.
Load balancers, caches, and queues are standard scaling tools.
CAP means that during a partition you choose consistency or availability.
Design is a series of trade-offs, not a single right answer.

← PreviousDesign Patterns Next →CI/CD