System Design roadmap

Defining functional requirements means mapping out exactly what features your system must provide and how users will interact with it. Before writing code or drawing boxes, you figure out user stories, core actions, and expected inputs and outputs.

Imagine building a photo-sharing app. The functional requirements state that users must be able to upload pictures, follow friends, and view a home feed. This stops you from guessing and keeps everyone aligned.

Getting this right matters because it forms the foundation of your entire architecture. Without clear requirements, you cannot make smart technical choices later.

• Focus strictly on user features and system behaviour
• Identify core user journeys and system inputs
• Prevent scope creep by setting clear boundaries
• Align technical goals with actual user needs

Non-functional requirements define how your system performs rather than what it does. They cover critical qualities like speed, uptime, security, and scalability under heavy loads.

Think of a ticketing website selling concert passes. While buying a ticket is the functional part, handling fifty thousand simultaneous buyers without crashing is the non-functional goal.

These requirements matter because they dictate your technology stack, database choices, and infrastructure costs. Ignoring them leads to slow apps and unhappy users.

• Define specific targets for latency and response time
• Plan for system availability and uptime percentages
• Ensure security and data privacy standards are met
• Consider maintenance and ease of future updates

Back-of-envelope estimations involve using quick mental math and rough approximations to figure out your system resource needs. You calculate storage, memory, and bandwidth based on expected user numbers.

If ten million users upload one photo a day, you can quickly estimate daily storage growth. This helps you spot bottlenecks before you spend any money.

These rough calculations matter because they guide your hardware decisions and help you defend your architectural choices during technical interviews.

• Use round numbers and easy powers of ten
• Estimate daily active users and request rates
• Calculate storage needs over months and years
• Identify obvious capacity bottlenecks early

Scaling is how you handle growth. Vertical scaling means buying a bigger server with more RAM and CPU, while horizontal scaling means adding more standard servers to share the load.

Imagine a busy coffee shop. Vertical scaling is hiring a super-fast barista, while horizontal scaling is opening extra checkout counters to serve more queues at once.

Horizontal scaling matters because single servers have physical limits. Distributing work across multiple machines keeps your applications resilient and infinitely expandable.

• Vertical scaling is simpler but has strict hardware limits
• Horizontal scaling adds more machines to share work
• Horizontal setups require stateless application design
• Cost efficiency improves with standard server sizes

A load balancer acts as a traffic cop sitting in front of your servers, distributing incoming user requests evenly across your server pool to prevent any single machine from crashing.

Think of a supermarket checkout supervisor directing customers to whichever till opens up next, ensuring no single queue gets too long.

Load balancers matter because they ensure high availability. If one server breaks, the balancer automatically sends traffic to the healthy ones instead.

• Distributes incoming traffic evenly across servers
• Performs health checks to spot broken nodes
• Can use round robin or least connection algorithms
• Provides a single public entry point for users

Domain Name System routing is the global phone book of the internet, translating human-readable website names into numerical server IP addresses so browsers know where to connect.

When you type a web address, global DNS servers quickly direct your request to the nearest data centre server, speeding up load times.

DNS routing matters because it enables fast, reliable global delivery and allows seamless failover if an entire data centre goes offline.

• Translates domain names into machine IP addresses
• Uses global caching to speed up lookups
• Routes users to geographically closest data centres
• Allows quick disaster recovery through IP updates

Caching involves storing copies of frequently accessed data in ultra-fast temporary memory, like RAM, so you do not have to query slower databases every time.

Imagine keeping your most used kitchen utensils on the counter instead of buried at the back of the pantry.

Caching matters because it slashes latency, reduces database load, and keeps applications snappy when millions of users are online at the same time.

• Stores hot data in fast memory layers
• Reduces database read pressure and latency
• Requires strategies for clearing stale data
• Common tools include Redis and Memcached

Choosing a database comes down to data structure. SQL relational databases use structured tables with strict schemas, while NoSQL databases offer flexible documents for unstructured data.

Think of a SQL database as a neat spreadsheet, whereas a NoSQL database is like a filing cabinet of varied folders.

This choice matters because picking the right database ensures your app can query data efficiently as your product features and data volume grow.

• SQL databases excel at complex relationships and joins
• NoSQL databases handle flexible, unstructured data well
• SQL guarantees strict ACID transaction safety
• NoSQL scales horizontally with greater ease

Database sharding is the process of splitting a massive single database table into smaller, independent pieces called shards, spread across multiple machines.

Imagine splitting a massive telephone directory into separate books by alphabetical surname ranges.

Sharding matters because single databases eventually run out of disk space and processing power. Sharding allows massive applications to handle endless write operations.

• Divides large tables across multiple database servers
• Improves write performance and storage limits
• Requires a smart shard key to distribute data evenly
• Adds complexity to cross-shard queries

Message queues let different parts of a system communicate asynchronously by placing tasks in a line to be processed one by one in the background.

Think of a restaurant ordering system where the waiter takes your order, puts the ticket on a spike for the chef, and immediately returns to serve other tables.

Message queues matter because they decouple services. If a background task fails, it will not crash the user-facing application.

• Allows asynchronous background task processing
• Decouples producers and consumers of messages
• Buffers traffic spikes safely without crashing
• Popular tools include RabbitMQ and Kafka

The CAP theorem states that a distributed data store can only provide two out of three guarantees simultaneously: Consistency, Availability, and Partition tolerance.

Imagine a team sharing notes across offices. If the phone lines break, do you stop sharing updates to ensure everyone reads the exact same notes, or keep working independently?

This theorem matters because it forces architects to make deliberate trade-offs when designing distributed databases for global scale.

• Choose between consistency and availability during network splits
• Partition tolerance is mandatory for distributed systems
• Helps guide database selection for specific needs
• Shapes how systems handle failure scenarios

Eventual consistency is a model where data updates propagate across a distributed system over time, meaning all replicas will match eventually rather than instantly.

Think of updating your profile picture online; it might take a few seconds to update across every global server.

This concept matters because it allows systems to remain fast and available globally without waiting for slow locks across distant continents.

• Updates spread across replicas asynchronously
• Prioritises high availability and low latency
• Data matches everywhere after a short delay
• Common in large distributed cloud databases

Designing a URL shortener is a classic system design challenge focused on handling massive read volumes and generating short, unique keys efficiently.

When a user enters a long link, the system generates a short hash, stores the mapping, and redirects future clicks instantly.

This practice matters because it tests your ability to handle high read-to-write ratios, caching, and simple database design under interview conditions.

• Handles high read volumes with heavy caching
• Generates collision-free short unique keys
• Uses simple key-value storage databases
• Implements fast HTTP redirection logic

Designing a chat application requires managing real-time, bidirectional messaging, connection pooling, and message delivery status across mobile and web clients.

Unlike traditional web requests, chat apps keep persistent connections open so messages push instantly to users.

This practice matters because it teaches you how to handle persistent state, WebSockets, and offline message storage effectively.

• Uses WebSockets for real-time bidirectional communication
• Manages persistent client connection pools
• Stores chat history in scalable NoSQL databases
• Handles offline message delivery gracefully

Designing a news feed involves balancing fan-out-on-write versus fan-out-on-read strategies to generate personalized social media timelines quickly.

When a user posts an update, the system either pushes it to all followers' feeds immediately or pulls posts when a user logs in.

This practice matters because it demonstrates your mastery of complex data pipelines, read-write trade-offs, and caching strategies.

• Compares fan-out-on-write versus fan-out-on-read approaches
• Handles celebrity accounts with millions of followers
• Uses caching to load timelines instantly
• Ranks posts using background worker algorithms