A Starting Point: The Common 8 (SLIC FAST)
Learn about the 'common 8' components that are used in several systems.
Introduction
While you don’t need to design a perfect solution in your interview, you do need to design a complete solution. And as we discussed in the previous chapter, you only have 20-25 minutes to design your solution after accounting for discussion time and introductions.
To help you get to the finish line with your design, I’d like to offer some tools and tips to help add structure to your design process in this chapter:
The common 8—A starting point to get you off the ground in the beginning of a system design solution.
Completing your solution with RESHADED—An 8-step method for completing a system design solution.
How to tackle a problem you’ve never seen before—Tips to prepare you for the unknown.
For this lesson, let’s focus on the common eight, which serve as some of the building blocks of any system.
Building blocks
When under pressure, it can be easy to forget some essential system components—which can make your design fall short. To help prevent missing any important components, you can start with a foundation of the most common components in a system.
At a high level, every system needs a few basic things. Imagine that you’re designing a single-family house. Two competing designs could each have a garage, two bathrooms, a living room, three bedrooms, and so on. Despite sharing these components, the details of the blueprints might be quite different.
Similarly, you’ll customize your System Design Interview solution according to your requirements, but the structure of the solution will have some basic features.
You can start by considering the eight most common system design components:
Components (SLIC) | Components (FAST) |
Search indexer | Front-end servers |
Load balancer | Analytics |
Interaction with a CDN | Storage |
Cache | Task queue |
Tip: To help you remember these components, you can refer to the mnemonic device: SLIC FAST.
Many systems have several of these components—but not all of them. However, remembering these eight can give you a valuable starting point from which you can build your solution for your particular requirements.
Let’s discuss these common components.
1. Search system
Where would we be without search? Most applications have a search component, enabling users to find data easily, such as a song on Spotify or a person on LinkedIn. When you have a content-rich system, there needs to be a way for users to find what they’re looking for.
A search system enables this, and that system generally has three components:
Crawler—Fetches content and creates documents.
Indexer—Builds a searchable index of available data.
Searcher—Runs users’ search queries on this index to return relevant information.
We could detail each of these components, but for now, suffice it to say that search needs to be part of your solution.
2. Load balancer
You can have all the servers in the world, but without a load balancer in front of them, you’re asking for problems. The load balancer works to divide incoming requests fairly among the pool of available servers. In the process, it prevents overloading or crashing your servers.
The load balancing layer is the first point of contact within a data center after the firewall. A load balancer is optional if a service entertains a few hundred or even a few thousand requests per second. However, for increasing client requests, load balancers can help in improving availability, scalability, and performance.
3. Interaction with a CDN
A Content Delivery Network (CDN) is a distributed network of servers that work together to deliver content to users over the internet. CDNs are designed to improve content delivery speed, reliability, and security by caching content closer to the end user.
Imagine someone in Argentina trying to access a video on Instagram. The servers are in the United States because that’s where the user who uploaded it lives. The video will have a long latency. Even with the fastest internet, the transmission will be slow.
We can deploy a CDN to improve performance, and the content will be replicated via the network. So if our user in Argentina opens Instagram and wants to watch a video, they will access that content through a server closer to their location—and they’ll experience lower latency.
In this way, CDNs are frequently used to optimize systems.
4. Cache
A cache is temporary data storage that speeds up data serving to requesting nodes by keeping the most frequently accessed entries in memory. Caches prevent performance degradation and database overloading. A cache can be implemented at various levels of the system architecture to optimize performance and reduce latency. For example, a web server may use a cache to store frequently accessed web pages or resources in memory, reducing the need to retrieve them from disk or generate them dynamically. Similarly, a database may use a cache to store frequently accessed data in memory, reducing the number of disk reads required to satisfy queries.
Let’s look at a simple example. Say a user request reaches your front-end server. The request retrieves data from the cache, which is called a cache hit, and it serves the user. If the data is unavailable in the cache, this is called a cache miss. Then, the data would be queried from the database. At the same time, the cache is populated with the new value to avoid a cache miss the next time the data is requested.
5. Front-end servers
A front-end server, also known as a web server, is a type of server that serves static content and responds to client requests on the World Wide Web. These servers are responsible for receiving HTTP requests from clients, typically web browsers, and responding with the appropriate content, including HTML, CSS, JavaScript, images, and other media files.
Front-end servers are an essential part of web architecture, as they are the first point of contact for clients accessing a web application or website. They often work with back-end servers, which handle dynamic content, database access, and other downstream functionalities.
6. Analytics
Analytics is a broad area with many forks. At a fundamental level, you want analytics to measure your system’s internal performance and external interactions.
Internally, you want to know how the system performs for users and if some part isn’t working. We want to ensure that the system is performing as expected and our services are all available.
Externally, you might want to know how many users have viewed or liked the content or interacted with your application. These analytics can be used to get valuable feedback from the users, and then that feedback can be used to improve your system.
During your interview, you’ll decide which analytics you want to focus on based on the requirements for your solution.
7. Storage
We use databases and other storage solutions to make it simpler to store, retrieve, modify, and delete data in connection with different procedures. Different storage solutions offer advantages and disadvantages. The database is a part of the persistence layer where data is stored permanently for later use. In particular, with the rise of data science, different data analytics are performed to improve efficiency and performance. The stored data can also be helpful in forecasting and planning.
Your storage solution might be a relational database, which is structured and organized with predetermined schemas.
Alternatively, you might use a non-relational database, which is unstructured and scattered with a dynamic schema. Non-relational databases are divided into various categories based on the nature of the operations and features.
Another option for unstructured data is a blob store, in which multimedia items are stored in a flat data organization pattern with no hierarchies.
8. Task queue
A task is a piece of computational work that requires resources. These resources might include CPU time, memory, storage, network bandwidth, and so on. These resources are limited, so a task queue (or task scheduler) allows you to complete a large number of tasks by scheduling work that cannot be done immediately. These queues are best used when handling
Let’s say a user uploads a video to a platform like YouTube, Facebook, or Instagram. Before the video becomes available, it must be encoded into different formats. Your system can’t ask the user to stand by for the encoding tasks to finish without ruining the user experience. Instead, your system could confirm the upload, inform the user the video will be available soon, and schedule the encoding work in a task queue behind the scenes.
Specializing your solution
Remembering these eight components will give you somewhere to start with your System Design solution. However, each solution is different.
To specialize your solution, you’ll need to tailor your design based on how you optimize for requirements and the trade-offs that come as a result of those requirements. Some designs won’t require each of the common 8 (or SLIC FAST) we’ve discussed, while others will require other components not listed in this lesson.
The better you understand building blocks, and how to use them, the better decisions you’ll make about when are where to use them.
Remember: We have only covered a limited number of building blocks here. In reality, the number of building blocks is much larger. For instance, Sequencer is one such building block we didn’t mention that generates unique IDs for identifying the flow of events across the system. You may want to come up with your own set of building blocks and mnemonic device to best prepare for your System Design Interview.
Quiz
Sometimes, even the best of us need a quick refresher. Do you feel confident about understanding the eight common building blocks in SLIC FAST?
Let’s put your knowledge to the test! Try revising your understanding in the interactive widget below.