Tutorial 1.2: System Architecture Fundamentals

Overview

Building a robust web application requires a solid understanding of system architecture: how components communicate, how to scale, and how to ensure reliability. This tutorial covers the essential building blocks, communication patterns, and design principles that every architect should know.

Why this matters: Systems that are not designed with architecture in mind often become fragile, unmaintainable, and expensive to operate. A good architecture is the foundation of a successful product.

1. Core System Components

A typical web system consists of several key parts:

Client: Browser, mobile app, or other consumer of the API.
Load Balancer: Distributes incoming traffic across multiple servers.
Application Servers: Execute business logic and handle requests.
Database: Primary data store (relational or NoSQL).
Cache: High‑speed storage for frequently accessed data (Redis, Memcached).
Message Queue: Asynchronous communication between services (RabbitMQ, Kafka).
CDN: Content delivery network for static assets.

These components are often distributed across multiple availability zones to improve resilience and performance.

2. Communication Protocols

HTTP/1.1, HTTP/2, HTTP/3

HTTP remains the backbone of the web. HTTP/2 introduced multiplexing and header compression; HTTP/3 uses QUIC (UDP‑based) for reduced latency.

WebSockets

Provides full‑duplex, real‑time communication. Ideal for chat, live updates, and gaming.

gRPC

A high‑performance RPC framework using Protocol Buffers. Efficient for microservice‑to‑microservice communication.

Message Queues

Enable asynchronous, decoupled communication. Producers send messages, consumers process them. Supports retries, dead‑letter queues, and event‑driven architectures.

3. Scalability Strategies

Vertical Scaling (Scale‑up)

Adding more CPU, RAM, or storage to a single machine. Simple but limited by hardware capacity.

Horizontal Scaling (Scale‑out)

Adding more machines. Requires load balancing, statelessness, and distributed data.

Microservices vs. Monoliths

Microservices scale independently, but introduce network latency and complexity. Monoliths are simpler to develop but harder to scale.

Database Sharding

Splitting data across multiple databases based on a shard key (e.g., user ID). Improves write throughput but complicates queries.

4. Caching & Performance

Caching reduces latency and database load. Common strategies:

Client‑side caching: Browser cache, local storage.
CDN caching: Edge‑cached static assets.
In‑memory cache: Redis/Memcached for application data.
Database query cache: Caching frequent query results.

Cache invalidation is the hard part. Patterns include TTL (time‑to‑live), write‑through, and cache‑aside (lazy loading).

5. CAP Theorem & Consistency

The CAP theorem states that a distributed system can provide at most two of three guarantees:

Consistency (C): Every read receives the most recent write.
Availability (A): Every request receives a (non‑error) response.
Partition tolerance (P): The system continues to operate despite network partitions.

In practice, CP systems (e.g., HBase) prioritise consistency, while AP systems (e.g., Cassandra) favour availability. Most web applications choose AP with eventual consistency, coupled with caching and retries.

“Choosing between consistency and availability is a business decision as much as a technical one.”

Quiz

Question 1

What is the primary purpose of a load balancer?

To store session data
To distribute incoming traffic across multiple servers
To run application logic
To serve static files

Show answer

B. To distribute incoming traffic across multiple servers.

Question 2

Which protocol enables real‑time, full‑duplex communication between client and server?

HTTP/1.1
WebSocket
FTP
SMTP

Show answer

B. WebSocket.

Question 3

In the CAP theorem, what does the ‘P’ stand for?

Performance
Partition tolerance
Precision
Persistence

Show answer

B. Partition tolerance.

Exercises

Exercise 1

A social media app experiences high traffic during peak hours. Which scalability strategy would you recommend, and why?

Sample answer

Horizontal scaling with auto‑scaling groups and a load balancer. This approach allows the system to add more application servers during peak hours and reduce them during low traffic, optimising cost and performance. Additionally, the database could be sharded by user ID to distribute write load.

Exercise 2

Explain a situation where you would choose a CP (Consistency + Partition tolerance) database over an AP (Availability + Partition tolerance) database.

Sample answer

Banking / financial systems: Consistency is critical because double‑spending or incorrect balances are unacceptable. In a network partition, it is better to reject requests (lose availability) than to serve stale or inconsistent data. Therefore, a CP database (like PostgreSQL with synchronous replication) would be preferred.

Homework

Homework 1

Design a caching strategy for an e‑commerce product catalogue. Describe where you would place caches, what TTL you would use, and how you would handle cache invalidation when a product is updated. (300–400 words)

Sample answer

Caching layers: Use a CDN for product images and static assets. Use Redis as an application‑level cache for product details, category listings, and search results.

TTL: Product details could have a TTL of 10 minutes; category listings 5 minutes; search results 1 minute (since they are more dynamic).

Invalidation: When a product is updated via the admin panel, trigger a cache invalidation event. Use a cache‑aside pattern: on a product update, delete the relevant keys from Redis, so the next request fetches fresh data from the database and repopulates the cache. For search results, consider using a versioned key (e.g., search:category:123:v2) and increment the version on updates.

Mini‑Project

Design a Scalable URL Shortener

Design the system architecture for a URL shortener service (like bit.ly) that supports:

100 million short URLs created per month
1 billion redirect requests per month
Low latency (< 50ms for redirects)

Include a description of the components, data storage, caching, and scaling strategy.

Sample design

Components:

API Gateway: Routes requests to appropriate services.
URL Creation Service: Generates a unique short code (base62 encoding of an incrementing ID or using a hash).
Redirection Service: Looks up the long URL by short code and returns a 302 redirect.
Database: Use a distributed NoSQL store (e.g., Cassandra or DynamoDB) for high write throughput and partition tolerance. Table: short_code → long_url, created_at, clicks.
Cache: Redis cache for popular short codes (LRU eviction, TTL 24h).
CDN: Not needed for redirects, but could cache static frontend.

Scaling: The creation service can be horizontally scaled behind a load balancer. The database is sharded by the short code (first few characters). The cache is distributed (Redis Cluster). To handle 1B redirects, the cache should have a high hit rate (>95%) to avoid database load.

Tutorial Summary

This tutorial covered the essential elements of system architecture: core components, communication protocols, scalability, caching, and the CAP theorem. You learned how to think about trade‑offs and design systems that are both performant and reliable. The practical exercises and mini‑project gave you a chance to apply these concepts to realistic scenarios.

Key takeaway: There is no one‑size‑fits‑all architecture. The best design depends on your specific requirements, constraints, and business goals. Always evaluate trade‑offs carefully.