my weekend w/ system design book

This past weekend, I locked myself in and got out of my comfort zone by going through the book "System Design Interview" by Alex Yu. I must say, it was such an eye-opener and proved how much I still didn't know about overall system design, trade-offs, strategies, and approaches to solving certain technical judgments in building high-reliability and enterprise solutions. It's far more complex than what we did on our personal projects, and while it still has a lot of similarities to what I learned during university, there are still many new advancements just in 2 to 3 years. Overall, I can say I view systems very differently after reading this. Anytime I open up YouTube, I start thinking about the streaming process hahaha, what a nerd. Of course, there's more to dive into as technology is constantly evolving, but I think I've understood what it takes to master some domains and to have justified reasons for any technical decision when working on certain products.

This article will serve as a quick run-through of what I managed to capture during the whole weekend. This was the part I meant when I said I want to go in-depth in Software Engineering and Infrastructure. This was just a glimpse or anything deeper, like a common design of Rate Limiter, Key Value Store, Unique Generated ID, and Notification Services, is far more complicated when dealing with enterprises with millions of Daily Active Users (DAU). How to avoid data loss and optimize for cost and efficiency still needs further exploration, but this will drive what I wanted to learn this year.

After going through this, the structure and essential for guiding the system design conversation. It will helps to reach an agreement on the proposed design or discuss any issues.

1. Functional & Non Functional Requirement

   1. Clarify the problem – Ask questions about scale, data requirements, and constraints.

   2. Define the scope – Focus on essential features first before optimizing.

2. Back of an Envelope Estimation

   Before building, you must calculate the scale.

   • The Latency Table: Understanding the speed difference between L1 cache, SSD, and a network round-trip.

   • Storage & Bandwidth: Estimating how many Petabytes of storage you'll need over 5 years so you can choose between a standard SQL DB or a Data Lake.

3. High Level Design

   1. Sketch the architecture – Identify key components like API gateway, load balancer, cache, database, and storage.

4. Deep Dive Design

   1. Discuss trade-offs – Explain why you chose certain technologies or patterns.

   2. Iterate and improve – End with optimizations and edge case handling.

personal top design choices

For starters, here are some of the designs I would recommend understanding. They are not only common but also helpful for gaining knowledge in certain areas.

1. URL Shorteners

The challenge here is simple but tricky: how do you turn a long URL into a short 7-character string without giving two different URLs the same short code? A common way to handle this is using a Hash Function, which offers two good solutions to the collision problem:

1. Use a hash function to convert a long URL into a 7-character string, like CRC32, MD5, or SHA-1. This is an old method, but it can be improved by adding a predefined string before hashing. The downside is that it can't completely avoid collisions, and checking the database for existing short URLs can be costly. Using bloom filters can help with this.

2. Base conversion is another popular method for URL shorteners.

Comparison Table are from ByteBytego.com

2. riders/drivers Uber or Grab - ish Platform

The first step is to define what you want to achieve, the scale, and what this platform can do, focusing on both Functional and Non-Functional aspects.

1. Users should be able to enter their start and destination points.

2. After a request, riders should be matched with nearby drivers.

3. Drivers should be able to accept or decline pickup/drop-off requests.

We can also mention additional features like CICD, Fault Tolerance, driver ratings, and Car Type to demonstrate our product thinking. Once the requirements are clear, we can identify the entities and APIs needed to meet these functional requirements. (Note: It's not always necessary to specify data types for entities; avoid dull moments during interviews and make sure to explain your choices). For security, mention that authentication is done using a Header JWT Token. After defining entities and APIs, move on to High-Level Design. In the Deep Dive section, senior individuals can showcase their expertise, but it's beneficial if a Mid-Level person can also explain their understanding of each component and share personal experiences. This approach aims to improve performance, reliability, and scalability.

more & more

To be honest, there's a lot to cover, but if I had to highlight one thing, it's that the patterns are quite similar in structure. It's expected that you won't know everything about each design, but you should be able to spark ideas and conversations about what you do know.

real-time message & streaming

• Messaging: The choice between WebSockets (for bi-directional, low-latency) and Long Polling (as a fallback).

• Video Streaming: Utilizing a DAG (Directed Acyclic Graph) for transcoding. When a video is uploaded, it’s split into chunks and processed in parallel to create different resolutions (1080p, 720p, 4k) for the CDN.

microservices

Although most of the book didn't cover microservices, it's likely because microservices aren't a typical system design. They are simply a way to separate services, similar to a monolith, but with different advantages and disadvantages for the team.

Benefits: Modularity, Scalability, Integration, Distributed Development, Fault Isolation
Criticism: Complexity, Distributed System Overhead, Data Management Challenges

Here's a repository worth exploring to understand microservices in practice:
GitHub - Retail Store Sample Microservices AWS

Below is the architecture:

general architecture

These are common features found in most systems and are worth mentioning in each one.

1. Scalability: Up vs. Out

• Vertical (Scale Up): Buying a bigger server. It’s simple but has a limit.

• Horizontal (Scale Out): Adding more servers. This is the industry standard for apps with high daily active users. We use Load Balancers and Database Sharding to make this work.

2. The CAP Theorem Trade-off

In a distributed system, you can only choose two.

• Banking? You choose Consistency (CP). It's better for the app to be "down" than to show the wrong balance.

• Social Media? You choose Availability (AP). It's okay if a "Like" takes 2 seconds to appear for your friend, as long as the feed keeps scrolling.

3. Reliability & Fault Tolerance

A senior engineer plans for failure.

• Idempotency: Essential for payments. If a user clicks "Pay" twice due to lag, an Idempotency Key ensures they are only charged once.

• Graceful Degradation: If the "Recommendations" service is down, the Netflix home screen should still show your "Continue Watching" list instead of a 404 error.

thoughts

In the Malaysian tech scene, you might not cover every detail in a 45-minute interview. However, the goal is to spark a conversation.

It's not about knowing everything; it's about having a toolkit of patterns like Caching, Asynchronous Processing (Kafka), and Rate Limiting and knowing when to use them. This weekend was just a glimpse, but it has definitely set the path for my learning this year.

I also created a personal repo where I generated various possible designs for any kind of system design for quick reference and refreshers. I set up the structure and let the OPUS 4.5 AI models generate comprehensive Markdown files.

some of the sauces

• Uber System Design Guide

• Hello Interview: Problem Breakdowns

• System Design Primer