For me, a system means a set of rules, processes, and triggers that guide the entire workflow. This helps you conserve energy and not have to figure things out in the moment. It keeps things productive, efficient, and consistent.

Now that the chaos has settled, I’ve been thinking a lot about systems – not just in life, but in tech. I wish I had applied the same principles of system design earlier.

In this article, we’re going to explore real-world system design examples from domains like gaming and job platforms. These industries don’t just scale massively – they also demand high availability, low latency, and seamless customer experiences. Understanding how they’re built is a powerful way to level up your thinking as a developer or architect.

What We’ll Cover

1. Introduction: What is System Design and Why Scale Matters

2. Approaches to System Design

   • 1. Bottom-Up Approach

   • 2. Top-Down Approach

   • 3. Hybrid Design

3. Important Concepts in System Design

   • Full Stack Web Application Components

   • How Computers Talk to Each Other (The Internet)

   • The Problem of Growth

   • Speeding Up Your Website with Caching and CDNs

   • Building Your Application: Monolith vs. Microservices

   • The APIs

   • Handling Real-Time Data

   • Databases

   • Understanding the CAP Theorem

   • Rate Limiting and Monitoring

4. Case Studies: Scaling in the Real World

   • Case Study 1: Scaling a Job Search Application

   • Case Study 2: Scaling an Online Gaming Application

5. Q&A

6. Final Notes

7. Conclusion

Introduction: What is System Design and Why Scale Matters

System design is the process of defining the architecture, modules, interfaces, and data of a system.

In other words, system design means explaining the different parts of a system, like its structure, building blocks (modules), and components.

It’s a process used to define, develop, and design a system in a way that meets the specific needs of a business or organisation.

The main goal of system design is to give enough information and details about the system, and to properly implement its parts using models and views. Let’s now talk about the different parts of a system.

Elements of a System:

• Architecture: This is a basic structure or model that shows how the system works, looks, and behaves.
  We often use flowcharts to explain and represent this architecture.

• Modules: These are smaller parts or sections of the system. Each module handles a specific task. When all modules are combined, they make the complete system.

• Components: These provide a specific function or a group of related functions. Components are usually made from one or more modules.

• Interfaces: This is the connection point where different parts (components) of the system exchange information with each other.

• Data: This refers to managing information and how it flows through the system.

Why System Design Matters

System design is important for a number of practical reasons. First, it can help companies and teams solve complex business problems and make sure they thoroughly analyse all requirements before building. It also reduces the chance that errors will be introduced into processes while making design phases more efficient and structured. Finally, it helps you efficiently gather and present your data in a useful format and improves the overall quality of the system.

Approaches to System Design

There are several methods you can use to approach system design. The main ones are:

1. Bottom-Up Approach

In this method, the design starts from the lowest-level components or subsystems. These small parts are gradually combined to form higher-level components. This process continues until the entire system is built as one complete structure.

The more abstraction we use, the higher the level of the design becomes.

Advantages:

• Components can be reused in other systems.

• It’s easier to identify risks early.

• It helps in hiding low-level technical details and can be combined with the top-down approach.

Disadvantages:

• It’s not very focused on the overall structure of the problem.

• Building high-quality bottom-up solutions is hard and time-consuming.

2. Top-Down Approach

Here, the design starts from the entire system, and you break it down into smaller subsystems and components as you go. Each of these subsystems then gets broken down further, step by step, creating a hierarchical structure.

In simple terms, you start with the big picture and keep dividing it until you reach the smallest parts of the system.

To sum up, design starts with defining the whole system, then continues by defining its subsystems and components. When all definitions are ready and fit together, the system is complete.

Advantages:

• The focus is on understanding the requirements first, which leads to a responsive and purpose-driven design.

• It’s easier to handle errors in interfaces between components.

Disadvantages:

• Components can’t be reused easily in other systems.

• The resulting architecture is often less flexible or not very clean.

3. Hybrid Design

The hybrid design approach is a mix of top-down and bottom-up methods. Instead of committing to just one way, it takes the strengths of both. You start by looking at the overall system (like in top-down) so that you don’t lose sight of the big picture. At the same time, you also focus on building solid, reusable modules or components (like in bottom-up).

In simple terms, you first plan the big picture, then create smaller components that can work independently, and finally combine everything into a cohesive system.

For instance, in our sports team site, we’d use top-down to define the whole fan journey (homepage → match details → live scores). But bottom-up, we’d build modular components like authentication or stats tracking, which can later be reused in new features like ticket booking or merchandise sales.

Advantages:

• You get the clarity of a top-down plan while still building reusable modules.

• It strikes a balance between high-level design and detailed implementation.

• Risks are easier to manage since you’re considering both structure and components.

Disadvantages:

• It can be complex to manage since you’re juggling two approaches.

• Requires more coordination between teams working on different levels.

• It might take more time compared to using a single approach.

Important Concepts in System Design

Before exploring core components, I want you to first understand two key concepts:

• Full stack web application components

• How computers talk to each other (via the internet)

Full Stack Web Application Components

A full-stack web application is a software application that combines both the frontend (what users see and interact with) and the backend (the server, database, and logic that power the app) into one complete system.

Generally, simple websites don’t require much system design – and in some cases, no system design at all. But when it comes to viral applications or platforms offering complex services, system design becomes essential. Most modern applications are full-stack applications, meaning they involve multiple interconnected layers working together.

Here’s a simplified overview of a typical full-stack application:

Before diving deep into each of these components, let me first give you a quick, high-level overview of what they are and how they fit into the bigger picture (starting from the bottom of the image above).

• Frontend – The user interface where people interact with your application.

• Backend – The logic and brain of the application that processes requests.

• APIs – The bridge that allows communication between frontend, backend, and external services.

• Database – The storage system where all your structured information lives.

• Server – The infrastructure that hosts, runs, and delivers your application.

Now, we need to understand how computers talk to each other.

How Computers Talk to Each Other (The Internet)

When you type a website's URL into the browser – and this site could be a simple portfolio site or a full stack app – how does your computer know where to send the request? It uses the Domain Name System (DNS). The DNS is like a phonebook for the internet – it translates a human-readable website name, like "example.com," into a unique numeric IP address that computers can understand.

Once your computer has the IP address, it uses communication protocols to send and receive data. One of the most important protocols is TCP. It breaks data into small, numbered packets. If a packet gets lost or arrives out of order, TCP ensures it's resent and reassembled correctly, making it a very reliable way to send data.

On top of TCP, we use higher-level protocols like HTTP. This is an application-level protocol that's easier for developers to use. It's the language your browser speaks to the server.

HTTPS is the same, but it adds an extra layer of encryption for security.

Now that we understand the basics of the Internet, remember that it serves billions of people worldwide.

Let’s break this down with a real-life example. Imagine you own a restaurant with a seating capacity of 50 people. One day, 10 extra guests arrive – and with a bit of adjustment, you still manage. But suddenly, a thousand more people show up at your door. What would you do then? It’s not just about adding more chairs and tables anymore – you’ll need extra food supplies, more staff, and a bigger setup to handle such massive traffic.

This simple example reflects the real challenge of growth and scalability. And that’s exactly what I’ll be diving into in the next chapter of this tutorial.

The Problem of Growth

Imagine you've built a simple website for a local sports team. Initially, it's just you and a few friends using it, so a single server is sufficient. This server holds all the website's logic and connects to a single database where player stats are stored.

As the team becomes more popular, though, more people visit your site, and it suddenly becomes slow. This is a scaling issue. Your system can't handle all the new traffic.

Scaling Your System: Two Main Ways

There are two ways to solve this. The first is vertical scaling. This is like giving your one server a bigger engine and more memory. You'd upgrade the CPU (the brain) or add more RAM (temporary memory). You could also use a faster disk storage like an SSD.

The problem is, you can only upgrade so much before you hit the limits of what's available. Plus, if that single server fails, your entire website goes down.

A better approach is horizontal scaling. This means adding more servers instead of just upgrading one. Now you have a team of servers, and each can handle a portion of the incoming user requests.

This approach allows for almost unlimited growth. It also creates redundancy and fault tolerance, because if one server breaks, the others can pick up the slack, and your site stays online.

Directing Traffic with a Load Balancer

With multiple servers, you need a way to make sure no single server gets overwhelmed. This is where a load balancer comes in. It acts like a traffic cop, sitting in front of your servers and directing each new request to the best-suited server. It uses different algorithms to decide where to send the traffic.

For example, the Round Robin method sends requests to servers one by one, in a cycle. Another method is Least Connection, which sends the request to the server that has the fewest active connections.

Speeding Up Your Website with Caching and CDNs

Imagine your website is now used by people all over the world. A user in another country might experience slow loading times because their request has to travel all the way to your servers.

To fix this, you can use a Content Delivery Network (CDN). A CDN is a network of servers around the world that store copies of your website's static files – like images, videos, and text files. When a user requests one of these files, the CDN serves it from the closest server, making the website load much faster for them.

This process is a form of caching. Caching is the general idea of making copies of data and storing them in a faster-to-access location. You can cache data on your server so it doesn't need to fetch the same player stats from the database every time. This reduces the load on your database and speeds up the entire application.

You can read more about the difference between CDNs and caching here.

Building Your Application: Monolith vs. Microservices

As your website grows, its code can become a tangled mess. You might start with a monolith, where all the features (like player stats and live scores, in our example) are built into a single, large program. A monolith is easier to start with, but it can be hard to manage and update.

A better approach for a large-scale application is to use a microservice architecture. This means breaking your application into smaller, independent services, each with a specific job. For example, one service could handle player stats and another could handle live scores. This makes your code more organised and easier to update, because a change in one service won't affect the others.

With microservices, you need an API Gateway. This acts as a single entry point for all user requests, directing them to the correct microservice behind the scenes. It also handles security and other common tasks.

The APIs

Think of APIs (Application Programming Interfaces) as the “middlemen” that let different pieces of software talk to each other.

In simple terms, an API is like a waiter in a restaurant. You (the user) tell the waiter what you want, the waiter takes your order to the kitchen (the system), and then brings the food (data or result) back to you.

Without APIs, your app, website, or software wouldn’t know how to ask another system for information or services.

For example, on our sports team website:

• The front-end (what fans see) uses an API to fetch player stats from the database.

• When someone buys match tickets, the API talks to the payment system to confirm the transaction.

• If fans want live score updates, the API makes sure the real-time data flows smoothly from the server to their screen.

So, APIs are important for system design because they shape how efficiently different systems connect, share data, and stay reliable under real-world use.

Your front-end and back-end services can communicate in several ways. The most common is a REST API. It's a standardised set of rules that uses HTTP to create a consistent way for a client and server to talk to each other. For example, it defines a standard way to signal a successful request ("OK") or a server error ("Internal Server Error").

When to use REST

• Best when: you need simplicity, broad adoption, and easy integration with browsers, mobile apps, or third-party services.

• Example: CRUD apps (blogging platforms, e-commerce sites, user management).

• Strength: Human-readable JSON, stateless, widely supported.

• Weakness: Over-fetching (getting more data than needed) or under-fetching (not enough data).

Another style is GraphQL. Instead of getting all the data a REST API provides, GraphQL lets the client ask for only the specific data it needs, which can make things faster and more efficient.

When to use GraphQL

• Best when: clients (like mobile apps) need fine-grained control over exactly what data they fetch.

• Example: social media feeds, dashboards with lots of widgets, mobile apps with limited bandwidth.

• Strength: Flexible queries, reduces over-fetching, strong typing system.

• Weakness: More complex server setup, which can cause performance issues if queries aren’t optimised.

For server-to-server communication, gRPC is often used. It's known for being very fast because it uses a more efficient data format called Protocol Buffers instead of JSON.

When to use gRPC

• Best when: services talk to each other in microservice architectures, and speed/efficiency is critical.

• Example: real-time systems (streaming, payments, IoT, machine learning inference).

• Strength: Super fast (binary Protocol Buffers), built-in support for streaming, strong contracts.

• Weakness: Not browser-native (needs extra tooling for web), harder debugging compared to REST

So to summarize based on my observations of what I have worked on so far:

• If you’re building something public-facing and widely consumed → go for REST.

• If your app has complex, dynamic queries from clients → go for GraphQL.

• If you’re dealing with high-performance internal service-to-service calls → go for gRPC.

In system design, choosing the right API style directly affects performance, scalability, and user experience. If you pick REST for its simplicity, GraphQL for its flexibility, or gRPC for its speed, you’re shaping how well your system can grow and adapt as real-world demands change.

Handling Real-Time Data

Real-time data handling is challenging because it requires maintaining an active connection to continuously transmit and receive data simultaneously. Traditional servers follow a request–response model, where data is only sent when explicitly requested.

That's where WebSockets come in. Unlike HTTP, which is a one-and-done request-and-response model, a WebSocket creates a continuous, two-way connection between the client and server. This allows the server to send updates to the user as soon as they happen, creating a real-time experience.

When microservices need to communicate without being directly connected, they can use message queues. A service sends a message to the queue, and another service picks it up when it's ready. This helps to decouple the services, so they don't have to worry about the other service being available at that exact moment.

On our sports site, WebSockets allow fans to see live scores instantly without refreshing the page – just like in chat apps, but here it keeps the excitement of the game alive in real time

Databases

Databases are a critical part of any full-stack application because they serve as the permanent home for user data. Once you’ve decided how to scale your servers and manage communication, you also need to consider the database layer. If everything else scales but the database does not, it can quickly become a bottleneck – leading to crashes, inconsistent records, or even data loss.

Many applications rely on relational databases (SQL), which store data in structured tables with rows and columns and are great for handling structured information. But for applications requiring high flexibility or handling massive unstructured datasets, NoSQL databases (like MongoDB or Cassandra) are often chosen. These databases don't follow the strict rules of SQL and are better for handling massive amounts of data.

They follow ACID properties:

• Atomicity: A transaction is all or nothing.

• Consistency: The data always remains in a valid state.

• Isolation: Multiple transactions don't interfere with each other.

• Durability: Once a transaction is complete, the data is permanently saved.

Just like with servers, you might need to scale your database. You can use sharding, which divides your data across multiple databases, or replication, which creates copies of your database to handle more read requests.

Understanding the CAP Theorem

When you're dealing with a distributed system and multiple databases, you inevitably face trade-offs. The CAP Theorem states that you can only guarantee two out of the following three properties at the same time:

• Consistency – Every user sees the same, most up-to-date data.

• Availability – The system is always available to respond to requests.

• Partition Tolerance – The system continues to operate even if a part of the network fails.

Now, from a system design perspective, this theorem forces us to make conscious architectural choices. For example, in financial applications (like banking), consistency often takes priority over availability because even a small inconsistency in balance data can cause chaos.

On the other hand, in social media feeds, availability and partition tolerance are often prioritised – it's okay if you see a slightly outdated post, but the system should never be down.

In the flow we’ve been discussing, whenever we introduce a new component or scale out across multiple regions, we need to reassess which two guarantees matter most for our business case. That decision directly drives what database technology we pick, how we design failover strategies, and what trade-offs we accept in user experience.

In short, the CAP theorem isn’t just a theory – it’s a practical compass. It guides us to balance user expectations, business priorities, and technical feasibility without breaking existing functionality, while still leaving room for future growth.

Rate Limiting and Monitoring

When designing a system, it’s not just about making it work – it’s about making it resilient. Two core guardrails here are rate limiting and monitoring.

What is Rate Limiting?

Rate limiting is the practice of controlling how many requests a user, client, or service can make to your system within a given timeframe. For example, you might cap an API at 100 calls per user per hour. This prevents abuse, safeguards against denial-of-service attempts, and ensures fair usage across all consumers.

Rate limiting comes into play any time your service is exposed publicly or internally to multiple clients.

To incorporate it, you can implement limits at the API gateway, reverse proxy (like NGINX), or within your service logic itself. Many cloud providers (AWS API Gateway, GCP Endpoints) also have built-in support.

What is Monitoring?

Monitoring is the practice of collecting metrics, logs, and traces from your system to understand its health in real time. Typical signals include:

• Error rates (for example, how often requests fail)

• Latency (how long requests take)

• Traffic volume (load across the system)

• Resource utilisation (CPU, memory, disk, and so on)

Monitoring is important from day one – it’s your feedback loop. Without it, you’re essentially flying blind.

To work it into your system, you can use observability stacks like Prometheus + Grafana, or managed solutions like Datadog, New Relic, or CloudWatch. You can also set alerts for threshold breaches (for example, 5% error rate spike).

In practice, rate limiting and monitoring work hand-in-hand. Rate limiting proactively guards against overload, while monitoring gives you visibility into whether the limits are working, whether scaling is needed, or whether a new type of failure is emerging.

For example, if you’ve designed a booking system (like in our earlier flow), rate limiting would ensure a single user can’t spam seat reservations, while monitoring would flag anomalies such as unusual spikes in request volume or sudden latency increases – helping you act before the system collapses.

Why Does This Matter for System Design?

These topics matter for good system design because they form the foundational building blocks of how modern applications actually operate in the real world. The way systems communicate, the type of APIs we adopt, and how we manage real-time interactions directly influence whether a product feels fast, reliable, and seamless – or slow and frustrating. In short, they determine how well the overall experience holds up when real users put it to the test.

When we develop a deeper understanding of how computers communicate, we begin to see the inner mechanics of client–server architecture – how APIs fetch data from databases through backend system calls. From this baseline, we can pivot into higher-level concerns:

• Scalability and resilience: Using load balancers to protect against server overload.

• Security: Introducing rate limiting to mitigate potential cyberattacks.

• Efficiency: Choosing the right type of API calls and leveraging caching/CDNs for speed and reduced overhead.

• Reliability: Implementing logging and monitoring to detect issues early and debug faster.

Together, these practices elevate a system from simply working to being robust, performant, and future-ready.

We’ve discussed the basics of all the most important concepts you’ll need to understand before building an end-to-end system. Now it’s time to deep dive into the case studies, where I’ll show you how different types of applications use system design to scale and serve billions of users.

I have picked services that are complex to build and handle multiple different types of components at a time, like gaming, education, and job search platforms.

Now let’s decode each of them together, and I’ll explain how I would scale the application if I were the developer building it.

Case Studies: Scaling in the Real World

System design is best understood when you see it in action. To show how principles like scaling, caching, load balancing, and real-time data management come together, let’s walk through two very different types of applications:

• A job search platform (focused on structured data and reliability).

• An online gaming platform (focused on real-time speed and responsiveness).

Looking at both will show you that, while the tools and concepts may be similar, the way we apply them depends on the type of system we’re building.

Both are high-traffic platforms, but with totally different needs. The job portal is about accuracy, reliability, and data-driven workflows, while the gaming platform is about instant responsiveness, fairness, and global reach.

In a job portal, a 1-second delay just means waiting. In a gaming app, a 1-second delay could mean losing the match. Both are failures – but for completely different reasons, and with different consequences.

Together, they show how the same building blocks of system design (scaling, caching, APIs, monitoring) are applied differently depending on context.

Case Study 1: Scaling a Job Search Application

A job search platform is one of the most used applications nowadays, as there are always people looking for a job. And there are many different job portals out there that handle the complete process, from finding jobs to user onboarding.

We’ll look at an example site called Upstaff. It’s a platform that focuses on hiring AI engineers as its core service (although it services other job profiles as well). At its core, it handles structured information – things like user profiles, job postings, and applications.

Day one, you have a few hundred users. On day one hundred, you may have tens of thousands. And in a year? Possibly millions. That growth means you have to think about scale, speed, and data integrity from the start.

🔹 The Core Components

• User Management: registration, login, and role-based access (job seeker vs employer).

• User Profiles: résumés, skills, preferences, stored in structured databases.

• Job Posting and Listings: employers create jobs, seekers browse/search/filter.

• Application Tracking: Every job seeker’s application status needs to be accurate and up to date.

• Recommendation Engine: jobs matched to users based on history and profile.

• Notifications: alerts for new job matches, recruiter replies, deadlines.

Every one of these features depends on the system’s ability to handle large amounts of structured data – and handle it reliably.

Step 1: Starting Small

At the beginning, everything can run on one server with a single database. This setup is enough for a few thousand users.

Step 2: Growth and Traffic Spikes

As more users join, the single server starts to slow down. To fix this, we add a load balancer and scale horizontally – adding multiple servers that share the traffic.

Step 3: Database Challenges

Soon, the database becomes the bottleneck. Searching across thousands of jobs slows things down. To fix this, we:

• Use sharding (split the database by user IDs or job IDs).

• Add a cache (like Redis) to store frequent queries such as “Software Engineer in New York.”

• Use a CDN to deliver logos, profile pictures, and other static files faster.

Step 4: Heavy Features

New features like a résumé parser or recommendation engine require extra computing power. Instead of overloading the main app, we move these into separate microservices.

Step 5: Security and Reliability

Finally, as traffic grows, we add:

• Rate limiting to stop any one user from spamming APIs.

• Monitoring to track errors, latency, and user activity in real time.

• API Gateway to ensure all requests are secure and validated. Here is an overview of the entire system scaling in an image :

This example shows how careful planning makes growth smooth. By scaling horizontally, caching smartly, and splitting heavy features into microservices, a job portal like Upstaff can handle millions of users without breaking.

Case Study 2: Scaling an Online Gaming Application

Now let’s flip the script. In a gaming platform like this site, speed and responsiveness matter more than anything. A 1-second delay in a job search is annoying. But in gaming, a 1-second delay can make players quit forever. Unlike job portals, the biggest challenge here is real-time responsiveness. A tiny delay can ruin the user experience.

🔹 The Core Components

• User Management Service: accounts, profiles, and login.

• Game Lobby and Matchmaking: pair players by skill, region, and latency.

• Game Server Manager: spin up and manage live matches.

• Real-Time Communication: powered by WebSockets or UDP for low latency.

• Game State Store (Redis): fast sync of health, scores, and positions.

• Leaderboard & Stats Engine: global rankings, achievements, and progress.

• In-Game Economy: coins, tokens, inventory.

• Payment Gateway: subscriptions and purchases.

• Anti-Cheat Security Layer: fairness across all players.

• Monitoring and Logging: server uptime, latency, and crash reports.

Unlike a job portal, every millisecond counts.

Step 1: Starting Small

At first, one powerful server is enough to run both the game logic and user accounts. With just a few players, things run smoothly.

Step 2: More Players, More Problems

As millions of players log in, the single server crashes. To fix this, we:

• Add a Game Server Manager that spins up separate servers for each match.

• Introduce a load balancer that assigns players to available servers.

Step 3: Real-Time Data Handling

In gaming, speed is everything. Instead of slow HTTP, we switch to WebSockets or UDP for instant communication. To keep everyone’s game view in sync:

• Use in-memory databases like Redis for positions, scores, and health.

• Update leaderboards in near real time.

Step 4: Scaling Features

Other services run in parallel:

• Matchmaking service pairs players by skill, location, and latency.

• Economy service manages coins, rewards, and in-game items.

• Payment gateway handles subscriptions and purchases securely.

• Notification system sends updates like “new event starting.”

Step 5: Global Expansion and Security

When the game expands worldwide:

• Use a CDN to deliver maps and skins quickly to all regions.

• Add an Anti-Cheat layer to detect and block unfair play.

• Build an Admin and Monitoring panel to track system health and user behavior.

In gaming, system design focuses less on structured data and more on low latency, real-time communication, and fairness. Scaling here means keeping gameplay smooth and secure, even when millions of players join at once. Here is the image representation of the complete game platform system design

Why Both Case Studies Matter

You might wonder – why show two different systems instead of just one? The answer is that system design isn’t “one-size-fits-all.”

• The job portal teaches us how to scale structured, data-heavy applications where reliability and accuracy matter most.

• The gaming platform shows us how to design for speed, real-time communication, and fairness under extreme load.

Together, these examples prove that the same system design principles of scaling, caching, monitoring, and microservices apply everywhere. What changes is how you use them to solve the unique challenges of your platform.

Q&A

How to get into system design if you don’t understand anything (yet)?

I get this question all the time – and the first thing you need to know is that system design isn’t some separate, elite domain. It’s an additional skill that complements your development journey.

If you're a full-stack developer (or aiming to be one), learning system design gives you a huge edge. After all, building an app isn't just about making it work – it’s about making it work well at scale.

So if you’re just starting and don’t even know how to become a full-stack developer yet, start there. Learn to build applications first, and then system design will start making a lot more sense. Read this guide How to Become a Full-Stack Developer in 2025 (and Get a Job) – A Handbook for Beginners to learn how to become a full-stack developer.

How do you understand system design concepts?

The short answer: with time and consistent practice.

Think of it like this: if you know how to use a pencil, it’s up to you whether you use it to sketch or to write. The pencil is just a tool. Similarly, in system design, once you understand the core concepts, it’s about knowing when and where to apply them. The rest – frameworks, tools, and technologies – are just means to an end.

It’s not about memorising patterns, it’s about developing the instinct to use the right building blocks at the right time.

What tools should you know before diving into system design?

The truth is, the list keeps growing. New tools and platforms are constantly emerging. But in my experience, having a solid foundation in the following areas makes a huge difference:

• Full Stack Development – so you understand how both frontend and backend systems interact.

• Cloud Platforms (like AWS, GCP, or Azure) – because most modern systems are cloud-native.

• CI/CD Pipelines – for automating testing, integration, and deployment.

• Deployment Strategies – to know how to roll out new changes with minimal risk.

Mastering these gives you the technical muscle to design systems that are scalable, reliable, and production-ready. I am a frontend developer, why should I know the system design

What resources should I study to learn system design?

In my last article, I shared all the resources that helped me learn system design.

System design is crucial for building reliable, high-performance applications. I explored the following resources:

• Free GitHub system design repository

• Another free GitHub system design repository

• Free System Design Handbook

• Free Hands-on System Design Learning Platform

• Free Intro to System Design Blog

Case studies and real-world architectures can also help you understand large-scale systems. You can follow any big tech engineering blog (Uber has a great one).

For high-level concepts, I went through the Grokking System Design course. It’s a paid resource, and I used it to deepen my understanding of system design. It’s not mandatory, but it helped me think about architecture at scale.

Note: there are other sites and courses out there of course, but I only share what I have personally experienced and used, and I focus on FREE material first.

Where to practice system design

This is where real learning begins. Start by picking any existing application from the internet, just like I did. Google something specific, like “job application portal,” but avoid the results on the first page. Those apps are usually well-optimised and already follow best practices in system design.

Instead, dig deeper and explore results from the second or third page. Look for an app that seems to be in its early stages.

Once you find one, try to understand how the entire application works. Break it down into its core components and then imagine what would happen if that app started receiving 1 million users a day. You’ll naturally begin to see what system design elements are needed to handle that kind of load.

Final Notes

Learning system design becomes much easier when you’ve already built something. Let’s say you’ve created an app and now you're thinking about how to scale it – that’s where real learning begins. The moment you start writing down your requirements (like how your app should behave when it starts getting more traffic), you naturally begin to develop system-level thinking. It’s this process of planning and anticipating real-world usage that turns theory into a practical skill.

Conclusion

Full Stack + System Design = The Ultimate Developer Stack 🔥

By mastering these skills, you can turn any idea into a real-world product, secure high-paying jobs, and even start your tech venture.

Now it's your turn – what are you building next? Let me know!

That’s all from my side. If you found this article helpful, feel free to share it and connect with me. I’m always open to new opportunities:

• Follow me on X: Prankur's Twitter

• Connect with me on LinkedIn: Prankur's LinkedIn

• Follow me on GitHub: Prankur’s Github

• View my Portfolio: Prankur's Portfolio

These terms are sometimes used interchangeably by architects and developers. They are not, however, the same thing – and understanding the differences can save you many headaches, as well as time and money.

This article will go through the differences between the three terms and explain how you can implement them in AWS.

Highly Available vs Fault Tolerant vs Disaster Recovery

A highly available system is one that aims to be online as often as possible. While downtime can still occur in a highly available system, the aim of high availability is to limit the duration of the downtime, not to completely eliminate it.

A fault tolerant system is one that can operate through a fault without any downtime. Fault tolerance aims to avoid downtime completely.

In a complete system failure however, high availability and fault tolerance are not enough. Disaster recovery describes how the system can continue to operate when the cushion of high availability and fault tolerance disappears in a system wide failure.

What Does High Availability Mean?

First, let's describe what high availability is not. High availability does not mean that the system never fails or never experiences downtime. A highly available system is simply one that aims to be online as often as possible.

Imagine we have a pizza restaurant that is open 24 hours every day for 365 days. If that restaurant only has one chef, then its availability – that is, its ability to process orders – will not be 100%. This is because a single chef can only work for about eight hours a day with a one hour break – or effectively seven hours a day, for seven days in a week.

The chef can therefore only work for 49 hours in a week out of a possible 168 hours. This restaurant has an availability of 29%.

A low availability restaurant

This is of course not a high enough availability for a restaurant that wants to be open for 24 hours in a day throughout the year.

So how do we get a higher availability for the restaurant? Hire more chefs. If we have four chefs working six hour shifts in a day for seven days in a week, this gives us a theoretical availability of 100%.

A higher availability restaurant

This 100% availability is only theoretical because it assumes no chef misses work in an entire year. This is a poor assumption as chefs can get sick, their cars can break down on the way to work, or they may have to leave work early to pick up their kids.

Let's say all this chef downtime adds up to five hours in a year. This gives you an availability of 99.94%.

How can you make the restaurant even more available? Hire standby chefs that are ready to come to the restaurant at a moment's notice. But this comes at a steep price since you have to pay these chefs to wait until they are needed.

What these standby chefs give you is the ability to quickly recover from not having enough chefs to meet customer orders. You can never have 100% availability because of the constraints of reality. You can only approach an availability of 100% at an increasingly steep price.

What is Availability in a System?

Availability is the probability that a system will be able to respond to a request.

Note that high availability has nothing to say about the quality of the pizzas or how quickly they are delivered. High availability is simply concerned with the ability of the restaurant to respond to pizza orders from customers.

The major cloud providers typically have SLAs that describe the availability of a system.

Take a blob storage system, for example. AWS S3 standard has an availability SLA of 99.99%. This is the same figure for Azure blob storage and Google cloud storage.

What exactly does 99.99% availability mean? It means that in any year, there is a 99.99% probability that the system will be online. An uptime of 99.99% equals a downtime of 0.01%. This is equivalent to a downtime of approximately 53 minutes - just under an hour for an entire year.

How about an availability of 99.9%? Such a system would have a downtime of 0.1% which is 8.8 hours in a year.

While 99.9% availability may seem high, for a bank processing payments, air traffic control system, or any other critical system, such amount of downtime may simply be unacceptable.

What is the right amount of availability you should target? That depends on the requirements of the system you are building.

You are of course constrained by the availability SLAs of the cloud providers, so there is limited flexibility in achieving say 99.999% availability for a blob storage system, for example. And, the higher the availability you want to achieve, the more expensive and complex the solution becomes.

What Does Fault Tolerance Mean?

If a failure within a system occurs, can the system continue to operate without any disruption? If it can, then the system is fault tolerant.

So what is the difference between high availability and fault tolerance? With a highly available system, failures that cause downtime will occur, but rarely. The system is also able to recover from such failures. But when the system is down, it cannot respond to requests.

In a fault tolerant system, the system can continue to operate in spite of a failure.

Let's use the pizza restaurant as an example again. If the restaurant experiences a power outage, then no amount of chefs in the kitchen or chefs on standby will help with making pizzas for customers since the ovens need a power supply.

A backup generator that kicks in immediately when a power loss is experienced makes the restaurant fault tolerant.

Another good example of this is a commercial aircraft powered by jet engines. These aircraft are built to be fault tolerant so in the event that one engine fails, the aircraft can continue to fly and land without disruption or having to fix the failed engine in flight.

Helicopters or single engine aircraft, on the other hand, are not fault tolerant. A failure of the engine means the aircraft cannot fly. Such failures are usually catastrophic and partly explain the higher rate of helicopter and single engine aircraft crashes compared to dual engine aircraft.

An aircraft with two engines is fault tolerant

Helicopters and single engine aircraft are not fault tolerant

What Does Disaster Recovery Mean?

If the scale of the system failure is so large that the high availability and fault tolerance of the system are effectively neutralised, can the system continue to operate?

Let's go back to the restaurant example. If a fire, flood, or any other disaster befalls your pizza restaurant, how can you continue to make pizzas for your customers?

This is a somewhat facetious example since in the event of a fire, worrying about customer orders is not the main priority – but the logic of the example still holds.

In this instance, high availability is of no help. Having an infinite number of chefs in the kitchen or on standby in a restaurant engulfed in flames = no pizzas for customers.

Fault tolerance is also of no help. A backup generator is useless for the appliances it is meant to power if they have been destroyed.

The only way the system (restaurant) can continue to operate is by routing orders to another nearby restaurant unaffected by the fire. Disaster recovery is a proactive plan of action that details how to recover after a disaster has happened.

Bringing it All Together

Now, let's look at a single architecture that is simultaneously highly available, fault tolerant, and has built-in disaster recovery.

All in one - high availability, fault tolerance, and disaster recovery in a single architecture

The architecture above shows a multi-availability zone (AZ) Relational Database Service (Amazon RDS) deployment. It shows an RDS database with a standby instance in a separate AZ, a single read-only replica, and an S3 bucket used to store backups of the database on a daily basis.

This RDS is a fully managed DB as a service offering from AWS where AWS manages the underlying hardware, software, and application of the DB. You can find more information here on AWS RDS and availability zones.

Now let's dissect how this system would work and how the design ensures it is highly available, fault tolerant and can recover from a disaster.

How High Availability is Achieved

The primary RDS instance in AZ A synchronously replicates its data to the standby instance in AZ B.

With synchronous replication, the primary instance waits until the standby has received the latest write operation before the transaction is recorded as successful. This ensures that both databases have identical information – that is, they are consistent, admittedly at the expense of increased transaction latency.

The primary and standby instances are in an active-passive configuration. Only the primary receives read and write request. The job of the standby is to simply take over as the primary in the event of a failure of the primary instance.

The time it takes to failover from the primary to the standby instance is called the Recovery Time Objective (RTO). The RTO simply describes how long it takes to recover from a failure. In this case, the failover time for RDS in a multi-AZ configuration is currently between 1-2 minutes.

The standby instance has one purpose: to increase the availability of the system. If the primary instance fails, or if the entire AZ A goes down, the standby instance in a separate AZ will be promoted to the primary. This failover process takes 1-2 minutes. That is 1-2 minutes of downtime.

Recall that high availability is not about preventing downtime, but simply reducing it. Without a standby instance, there is a high probability that downtime will exceed the 1-2 mins it takes to recover with a standby instance.

Note that the standby instance does not help with fault tolerance, since the failure of the primary will still lead to downtime.

How Fault Tolerance is Achieved

To eliminate downtime, you need a configuration that involves no failover. This is a job for read-only replicas. These are asynchronously replicated copies of the primary instance. Writes are only made to the primary instance. Read replicas are, as the name implies, read only.

Such an approach is ideal for read heavy application since read replicas can remove the additional burden of read requests from the primary instance.

In asynchronous replication, writes to a primary instance do not wait for a response from the read-only replica before the transaction is recorded as a success. This means that, for a time, data across the primary and read replica may not be identical (but rather, inconsistent) after a write to the primary.

This eventual consistency (a topic for another article) is a drawback of asynchronous replication. The benefit of asynchronous replication is that it does not wait for the read replica to respond before the transaction is recorded as a success.

This is important because if the read replica is down or there is a network failure, the primary can still accept subsequent writes without waiting for a response from the read replica, confirming that the previous write was successfully replicated.

The architecture above has two replicas: one synchronous and the other asynchronous. If all replicas are synchronous, then a failure in the standby replica or the read only replica, or even a network failure, brings the entire cluster down. This is a fragile design that exposes the entire system to failure if a single component fails. Having some replicas that are synchronous and others that are asynchronous improves the fault tolerance of the system.

Where else does fault tolerance come in? Like an aircraft with two jet engines that provide thrust, a read replica and a primary can work together simultaneously. The the primary instance processes writes and the read replica responds to read requests.

Failure of the primary instance has no effect on the read replica's ability to respond to read requests. There is no downtime for reads since only the read replica responds to reads.

How about writes? The read replica can be promoted to a primary, although with RDS, this is currently a manual process.

How Disaster Recovery is Achieved

With the architecture above, you can handle disaster recovery in two ways. There is no constraint to limit disaster recovery to only one approach, so you can use both at the same time. And in fact, the more approaches you have, the better, since this provides extra redundancy.

Ultimately, you should weigh all this against cost, as implementing disaster recovery strategies can be expensive.

The first method is through automatic backups. Backups are taken from the standby instance, preventing performance degradation of the primary instance that has to serve writes (and reads if not configured with a read replica). Since there is synchronous replication between the primary and the standby, we have a guarantee that the standby is an up to date copy of the primary, so it's ideal to take backups from.

With RDS, backups are taken on a fixed schedule once a day (specified by you) and stored in an S3 bucket. Since this is an entirely separate component, any RDS-related system-wide failures will not affect the durability of the backups.

With backups, a loss of the primary, standby, and read-replicas does not equal a permanent loss of data. Backups can then be used to restore the database to a new DB instance.

The second method is to promote the read-only replica to a standalone instance if the primary instance fails. The read replica can be configured in another AWS region. This way, if there is a disaster on a regional scale where multiple AZs are down, a cross regional read replica will ensure that another instance is available in a different AWS region to serve read and write requests.

This is analogous to diverting orders to another restaurant in the event of a fire.

How different components improve the availability, fault tolerance and disaster recovery of a solution

Wrapping Up

Availability is measured in percentages - the larger the number, the more available the system is (hence less downtime).

Very few systems aim for 100% availability – although pacemakers are a notable exception. An availability of 99.999% has a downtime of 0.001% = 5 minutes of downtime in a year. This tends to be the upper limit for most software systems.

Aiming for higher levels of availability above this is increasingly complicated, expensive, and often unnecessary. This is especially true when you consider that the software system you are building relies on infrastructure like the power grid and internet service providers, which may have lower availability levels.

Fault tolerance, on other hand, cannot be measured. Your design is either fault tolerant or it is not. Similarly, disaster recovery cannot be measured. You either have a plan of action that precisely outlines how your system can recover from a disaster or you do not.

Knowing the difference between high availability, fault tolerance, and disaster recovery is important. It ensures you are building the correct architecture based on customer needs.

Over-engineering a solution by providing disaster recovery when all that is required is high availability or fault tolerance is often an expensive and complex exercise.

On the other hand, under-engineering a solution by only providing high availability when fault tolerance is required can lead to severe consequences for some critical systems that cannot afford any downtime.

System Design is an important topic to understand if you want to advance further in your career as a software engineer. Even if you are just beginning your coding journey, it's a good idea to get a head start on learning about system design.

Early in your career you will mostly just be tested on your coding ability. In higher level interviews, however, there will often be a greater focus on testing your ability and experience at designing applications.

The biggest struggle engineers have with system design interviews is that they are more open-ended and there isn't any single correct answer. This lack of structure can be intimidating, so my goal with this article is to give you a roadmap for navigating these types of interviews with confidence.

What this article will cover:

• What is a system design interview and why they are used
• The main stages of a system design interview
• Example interview problem – Design YouTube

Video Tutorial

You can also watch this tutorial on YouTube if you like:

And I've created a playlist of videos on specific topics related to system design and web architecture:

System Design Interview Overview

At first glance it seems silly to ask somebody to design a huge app like Twitter or YouTube in 45-60 minutes. These apps were designed over a period of years by hundreds of engineers working together, so it's clearly an impossible task to do in a short interview.

There are two main reasons why companies use these types of interviews. The first is, of course, to test your knowledge about the technologies being discussed. They want you to go deep enough to make sure you aren't just throwing buzzwords around without understanding how things actually work.

The second reason might be more important, though. The system design interview is a way to simulate a realistic scenario where you are working together with the interviewer to determine the best design decision.

Getting the perfect answer isn't necessarily the most important thing here – it's some of the other things you can show, like:

• How do you handle being challenged? Do you get defensive or take feedback with a positive attitude? Are you stubborn or narrow-minded?
• Do you show knowledge of the various tradeoffs certain design decisions involve? There's a big difference between blindly making a decision and not realizing the consequences, and knowing the pros/cons and accepting the tradeoffs.
• Are you able to effectively communicate and if necessary explain complex technical concepts in an easy to understand way?
• Are you candidate somebody the interviewer would want to work with long term? Even if somebody is a genius, if they are miserable to work with they might not be a good hire.

Stages of a System Design Interview

In this section you'll learn a general framework for structuring how to handle a problem during a system design interview.

Clarify the problem and establish design scope

The first thing you'll want to do after your interviewer gives you the problem is to take a few minutes to ask some clarifying questions and figure out what exactly they are looking for.

The worst thing you could do here is just start off in the completely wrong direction because you didn't take the time to ask a few questions. You have a limited amount of time during the interview, so you want to make sure you focus on what's important.

Here are some examples of questions you might ask:

What are the use cases / features of the app?

In this article we will be using YouTube as an example. There are hundreds of different features you could design like ad delivery, authentication, recommendation algorithms, comments, video upload, video processing, and many others.

During an interview you only have time to cover a few of those, so make sure to ask the interviewer questions to figure out what they want you to focus on designing.

How many users are expected / what is the likely traffic volume?

The complexity of the system will depend on the amount of traffic it needs to handle, so make sure to gather this information.

You don't want to over-engineer things if the traffic is relatively low and you also don't want to get stuck with an app that can't scale because you didn't design it properly.

Ask questions like how many users the app will have, the average amount of data per request, how long data needs to be stored, and how reliable and available does the system need to be?

This step is going to help you beyond just getting more information to work with. You're also showing the interviewer that you understand how to gather information about a vague problem.

Determine Rough Capacity Estimates

Using the information you gathered during the first step, you can begin to make some rough estimates and generalizations for things like storage and bandwidth requirements.

This process will involve some basic math like multiplying the number of users by the average request size and the amount of requests each user is expected to make daily.

Create a High Level Design

Here you want to create a rough architecture for the system. Draw out things like load balancers, web servers, app servers, task queues, database, caching, file storage, and so on. You should include all the core components you need to create the system.

Make sure to communicate with the interviewer during this stage and check to ensure that you aren't missing anything. While they probably won't tell you directly, they will give you a nudge in the right direction if you forgot about some crucial feature.

API Design

This part is almost cheating because you are using the structure of the interview to your advantage to confirm that you are on the right path.

The interviewer is never going to deliberately lead you down the wrong path, so once you've created your high level design you can start sketching out some rough API endpoints for each component.

For the YouTube example they might look something like this, depending on which features you are building:

• uploadVideo (userID, video, description, title)
• comment (userID, videoID, comment)
• viewVideo (videoID)
• videoSearch (query)

In some cases you might not need to drill down to this level. If the interview question is very high level like "design Youtube", you can probably skip this part. On the other hand if you get a more focused question like "design YouTube's comment system", it would make sense to go more in depth.

Create a Data Schema

At this point you should have a good idea of all the requirements and data needed for the application to work, so now you can plan out how your data is structured.

Depending on what you are building and the requirements, you'll need to weigh the costs and benefits of things like using a relational vs non-relational database. When modeling your data you'll also want to account for things like potential data partitioning and replication.

Take a Detailed Look at the Components

What happens during this section will mainly depend on the feedback of the interviewer. They will probably pick out a few specific components to focus on and ask why you made certain decisions.

The most important part here isn't necessarily being 100% right. Instead, it's to show that you didn't just blindly make decisions and understand exactly what tradeoffs you were making.

You should be able to propose alternate design decisions that could have been used and explain why you didn't use them.

How to Design YouTube

Now that you have a general idea of how a system design interview works and a framework for handling a system design problem, I'm going to show you how to put it all into practice using YouTube as an example.

Step 1 – Define Problem Scope and Requirements

This will be a high level problem where we implement a few of YouTube's major features without diving too in-depth on any of them. The features to focus on will be:

• Users can upload videos
• Users can view videos
• Users can comment on videos

Step 2 – Determine Capacity estimates

The two biggest capacity factors in an app handling large amounts of video like YouTube will be storing all that content and bandwidth requirements to deliver the content to users. In this section you'll learn how to make rough estimates for capacity requirements.

The main focus here is not on being highly accurate, but showing a logical thought process for calculating these numbers based on the information available to you.

In an interview you would be given the data, but in this case I'm using two key pieces of data that YouTube has made public:

• YouTube creators upload 500 hours of video every minute
• YouTube users watch 1 billion hours of video per day

You can use these numbers to calculate storage and bandwidth requirements with a few assumptions.

Bandwidth Calculation

Daily bandwidth calculation

To calculate an estimate for bandwidth, we start with the amount of video watched daily. The key assumption here is how much bandwidth is used per hour watched, as this would depend on the quality of video most users choose to watch.

The 3 Gigabyte estimate is based on a rough percentage of users watching in standard definition and others choosing HD or 4K, which consume much more bandwidth per hour watched.

The math here is fairly simple: multiply 1 billion hours by the average bandwidth of an hour of video, then divide that by 1000 to convert to terabytes, then divide by 1000 again to get to Petabytes. The final bandwidth estimate is 3,000 PB used daily.

Storage Calculation

Step by step calculations for storage

Based on a few assumptions we can calculate that YouTube will need to store around 2.16 Petabytes of new video every day. Here's how we get that number:

• Convert 500 hours to 30,000 minutes of video uploaded per minute
• Each minute of HD video is roughly 50 Megabytes due to having copies of each video in multiple formats. We multiply that by 30,000 minutes and then divide by 1000 to convert to Gigabytes.
• We then take the 1,500GB uploaded per minute and multiply by 60 then 24 to calculate the daily amount of video uploaded. We divide by 1000 again to convert Gigabytes to Terabytes
• Our final total is 2,160 Terabytes uploaded daily or 2.16 Petabytes

Step 3 – Database Design

For our database we will use a standard relational database like MySQL. The schema will look something like this:

This design is very simple but has the essentials that you'd need for a basic implementation. It would be a good idea to do some research into the differences between relational and non-relational databases so you understand what kind of situations each excel at and when to use them.

For certain apps with different requirements a NoSQL database might make sense. Often large systems will have many different services that use different types of databases depending on their needs.

Step 4 – High Level Design

That's a pretty complex diagram, so let me break down what's happening:

• Client – This could be a user on a mobile app or their computer trying to upload a video, make a comment, or watch a video
• CDN – A content distribution network is used to reduce latency and improve reliability when it comes to delivering static content like videos or images. A CDN works by storing content in data centers all around the world so that the content is closer to users. This results in reduced latency because requests travel a shorter distance. There's also an added benefit of content being stored in multiple locations so even if one location can't serve traffic for some reason, another location can.
• Load Balancers – A load balancer accepts requests and routes them to servers depending on a number of factors. At YouTube's scale, a single server can't handle all the traffic and you want replication to prevent a single point of failure. The load balancer can check the status of servers and verify they can handle traffic or choose another server that can handle the request.
• Services – You can think of this as the app layer of the system. Instead of using a single monolith to handle traffic, we'll use several microservices to handle specific tasks. The second box for each of these services in the diagram represents multiple servers running for each of them to increase reliability. If one replica of the service goes down, there's always another to step in and handle traffic.
• Data Stores – When using microservices it is generally best practice for each microservice to own its own data. If one service needs data from another they can access it through an API.
• Video Upload Process – Handling the video uploads will involve multiple steps, as trying to handle it synchronously with the app server would be fragile and reduce performance. I'll cover this more in depth in the next section

I don't want to go too in-depth on these individual components because I could write entire articles on any of them if I wanted to explain them fully.

If you are interested in a more detailed explanation you can check out the system design playlist I linked to above which has videos covering most of these concepts.

Step 5 – Go Over Specific Components and Details

At this stage you have a working design. Now let's look at some of the specific components in detail.

Video Upload

Video content is the lifeblood of YouTube, and it doesn't exist without it. This means that making it quick and easy for users to upload videos is probably the most important feature.

Imagine uploading a multi-gigabyte video to YouTube and then seeing the upload fail after 30 minutes when it's 95% done. To prevent this you'll want to support the ability for resuming uploads if the client's connection is lost temporarily. The uploaded video can then be stored with a distributed file system like HDFS.

Once the upload is complete there's still a lot more to do before the video is ready for users to access. The video needs to be encoded into multiple different quality formats, you need to generate thumbnails, and push copies of the video to the global CDN.

Again, at any stage one of these processes could fail. To prevent this you'll have a task queue to manage this process and retry the processing attempt if it fails at any stage.

Database Scaling

The database is often the bottleneck of an application. You will probably be tested on whether you understand some of the fundamental concepts around database scaling. This could include caching to handle read requests, sharding, and replication.

Conclusion

Hopefully this article has given you a better understanding of what to expect during a system design interview.

This article mainly focused on the structure of the interview itself rather than the concepts you need to understand to answer the questions given during the interview.

Two great resources for beginning to learn about that are:

A great article posted here on Free Code Camp News: https://www.freecodecamp.org/news/systems-design-for-interviews/

The system design primer repo on GitHub: https://github.com/donnemartin/system-design-primer

Both cover just about every major concept you need to know for your system design interview and should put you in a great position for success.

Architecture may sound like a “scary ” or overwhelming subject, but actually, applying logic and approaching the problem methodologically simplifies the process drastically.

When you architect a system, service, or feature, you actually design a solution to a problem in a specific context. The solution should answer a real need and solve the problem at hand.

Throughout the text, I’ll be using solution in order to emphasize that the systems, services, and features we build are part of a bigger flow.

When designing a solution think about the entire environment flow you affect.

• Think about what happens before the data reaches your code
• What triggers your feature or service
• Who sends it?
• Is it something automatic?
• Is it a user?

This will also help you think about tests and edge cases you want to address, what happens after, who would use it and how.

1.Understand the problem

Start from understating the problem at hand and understand your boundaries. Don’t optimize for an unknown future, focus on the current situation and most importantly, don’t make assumptions. Don’t limit yourself by requirements that are not there.

Make sure you have all the information you need to understand the problem, don’t be afraid to do research, Google is your friend ;)

_Photo by [Unsplash](https://unsplash.com/@rawpixel?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">rawpixel on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

2. Understand your boundaries and set priorities

Solution architecture is always a trade-off between concerns, such as resilience, security, data integrity, throughput, scalability, performance and of course cost.

Think about value vs friction

Understand your constraints. What are your must-haves. If you have a product team, work with them in order to understand the business need, impact and SLA’s. This will help you understand your considerations and limitations better.

Use data to make priorities, avoid assumptions when possible and be data-driven.

• How many users?
• Number of requests?
• Size of requests?

Test your service in order to estimate the resources that are needed.

Make sure you address the maximum rate you want to support and not only the average (look at percentage vs average).

Think about solving the problem and not just how to solve it. First think about the solution and only after that think about the implementation. When you free yourself from the expectation of how the solution should look like, you understand that a solution can be provided in many forms. It can be a system, service, feature, process or even documentation.

3. Ask WHY?

Challenging people and even yourself can be frustrating sometimes. But asking why can help you solve the real problem, understand the mandatory requirements and your boundaries, and can help you avoid mistakes and understand the motivation from the business side.

• Why is it a real pain?
• Why should it be done like this?
• Why it works like this today?

Challenge yourself and ask questions. It will help make better decisions and better solutions.

_Photo by [Unsplash](https://unsplash.com/@emilymorter?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Emily Morter on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

4. Your solution is not in a vacuum

Context is important. A startup of 4 people that needs to provide MVP and is limited by funds will and should solve a problem differently than a team in a big organization that needs to create a sustainable product that will need to be maintained by several teams.

Going back to my first statement, after you understand the problem think about the context.

• What are the tools you have at your disposal?
• Are you part of a big organization?
• Are there any limitations such as time or money?
• Who will maintain the solution?

Think about what is right for your situation, define what production ready means to you, and whether it should be highly available (HA). Think about the ROI. Should you address Edge cases?

• How would you design a solution that will return values from a database?
• And what if I told you that it would be used only once a week until the end of the year. Would it change your answer? Would it affect the design?
• If you have 1 day to build a solution would it be the same as if you had a month?

Think about growth. For different solutions and different companies, growth means different things. It can be from a scale perspective, such as supporting the growth of additional users. It can also be from a functionality perspective, where your solution should be flexible to enable other developers to add /modify functionality with ease.

5. Cost

As engineers and developers, we sometimes do not stop to think about the cost of our solutions and services. From my experience it is mostly due to lack of awareness and not willingness.

When we are at university, we are “pumped” with performance and complexity concerns, and taught to think about the efficiency of the solution. But when designing a product that will be used, we need to also think about efficiency with regards to cost. You can build an amazing stable and reliable service that provides value, but if its ROI is not high or if your company won’t be able to afford the cost, it will be axed in favor of other alternatives.

Remember, performance and infrastructure are not free.

6. Production deployment is only the beginning

An important concept that sometimes is neglected is maintenance. Is our system or service stable and easy to maintain, debug, troubleshoot and fix?

Production deployment is only the beginning of our solution. Make sure it can be easily maintained, make sure it is production ready and can serve real traffic and users. When developing your solution, think about end to end monitoring, focusing on application monitoring vs. utilization, and make sure to add logging and documentation.

When designing your solution, think about a simple and easy to maintain design, as much as the requirements allow for it of course.

As developers, we are sometimes drawn to new “flashy” and trendy technologies. Stop to think whether this technology is mature enough. Could it be maintained in production? Could a different stack be more efficient or offer fewer risks?

Wrapping up

To recap, if you want to architect the best solution EVER, start from understanding the problem and your limitations, and know the context of the solution you are trying to design for.

Then think about what happens with your solution after it’s up.

Unless you have unlimited funds (which is never the case), think about your solution’s cost and make sure that it maintainable.

If you liked what you read, be sure to ? it below!

Let me know in the comments ❤ if you like more architecture posts and/or would like me to deep dive about each of the points above.