Link-in-bio tools help creators share links, but they rarely show why a creator is worth following or partnering with. AInfluence changes this. It turns a single bio link into a complete creator profile, bringing featured content, product recommendations, audience appreciation, and brand collaboration opportunities together on one polished page. Followers discover more, brands see proof of influence, and creators gain more ways to turn attention into trust, revenue, and partnerships.

Know More @ AInfluence

Welcome to the 14th Episode of the System Design Weekly! Your weekly dose of byte-sized system design concepts.

In this episode, our agenda is small but interesting. We are going to discuss an algorithm called the Bully Algorithm. It is an algorithm for leader election in a distributed system.

We also bring to you a blog from Uber’s engineering team talking about intelligent load-management on their databases.

So, if all this sounds interesting to you, read on!

😤The Bully Algorithm

Distributed algorithms can rougly be divided into two categories: Leader-based and Leaderless.

In Leader-based algorithms, one or more nodes are designated leaders. Such nodes are then assigned important responsibilities for network to work normally.

The Bully Algorithm is used for electing a leader from a set of nodes in a distributed setting. The idea of the algorithm is pretty simple -

1. Each node in the system is assigned a unique priority number

2. At any point in time, the node with the highest priority of all the healthy nodes is designated the leader

To complete the specification of the algorithm, we need to discuss the case when a leader node goes offline.

When a leader node fails, other nodes will not be able to contact it any longer. When a node finds out about the missing leader, it issues a re-election request to all nodes with greater priority.

Out of all the nodes that respond to a node for re-election requests, the node selects the one with maximum priority and send its acknowledgement to proceed.

The node that received an acknowledgement proceeds by sending notification to all nodes, stating its leadership.

Problems with the Bully Algorithm

The Bully Algorithm comes with its own share of problems that we should know -

• High message overhead: In the worst case, each node could initiate re-election simultaneously and thus causing O(N²) message flow in the system.

• Reliance on Synchronous Communication: The algorithm heavily relies on synchronous communication between nodes which is not a reality in real world systems.

• The “Bully” Problem: In case of a flaky highest priority node, the node will cause re-election every time it leaves and come-back.

Because of all these problems, the Bully algorithm is rarely used in production grade systems. But it serves as a good case study!

🔦 Tech Spotlight!

In this week’s Tech Spotlight, we feature an insightful deep dive from the Uber Engineering team on evolving their database overload protection.

➥ How Uber Conquered Database Overload: The Journey from Static Rate-Limiting to Intelligent Load Management

Uber’s distributed databases, Docstore and Schemaless, handle tens of millions of requests per second. In this article, Uber engineers detail how they transitioned from static, quota-based rate limiting to Cinnamon: an intelligent, priority-aware load shedder powered by PID control loops.

By centralizing local and distributed signals (like follower commit lag), they reduced P99 latencies by ~70% and drastically improved system stability under heavy load. A masterclass in real-world distributed systems resilience!

That brings us to the close of this episode! If you enjoyed reading it, consider dropping in a ❤️ below and leaving a comment.

If you have worked on building distributed systems, you know that behind every design choice lies a fundamental trade-off.

→ “When a network partition hits, do you choose consistency or availability?”
→ “How do you shard data across nodes without creating hot spots?”

We break down the answers to these questions in this quick, bite-sized edition covering the CAP Theorem and the famous Sharding vs. Partitioning dilemma.

In the Tech Spotlight, we bring to you an article from the SerpApi team on reverse-engineering Protobuf schemas directly from binary payloads.

If all this sounds interesting to you, read on!

🧢The CAP Theorem

Imaging running a bank with two different branch offices (A and B). If the network wire connecting the two branches gets cut, can a customer deposit $100 at Branch A and immediately withdraw it at Branch B?

We have to make a choice. Either allow the withdrawl and risk giving away money that wasn’t received. Or, refuse the request until the network connection is restored.

This fundamental dilemma is the CAP Theorem in a nutshell.

Formulated by Eric Brewer, the CAP Theorem states that any distributed data store can only simultaneously guarantee two out of three properties:

• Consistency (C): Every read receives the most recent write or an error. All nodes see the exact same data at the same time.

• Availability (A): Every working node always responds to requests, even if the data is slightly out of date.

• Partition Tolerance (P): The system continues to operate despite arbitrary message loss or network failure between nodes.

In true distributed systems, network partition always happen. Thus, we only have two choices - Consistency+Partition (CP) or Availability+Partition (AP).

For an even cleaner explanation to the CAP Theorem, checkout the following post! 👇

🧩Sharding Vs Partitioning - What is the Difference?

Both Partitioning and Sharding break large datasets into smaller pieces, but the key difference is where those pieces live.

Partitioning splits a large table into smaller partitions within the same database.

Sharding takes that idea further by distributing those partitions across multiple database servers.

Partitioning can make queries and data management more efficient, while sharding helps scale storage, reads, and writes across multiple servers.

But sharding comes with additional complexity. Balancing data, managing shards, and handling resharding can all be challenging!

So which one should you use?

It depends on your workload, data size, traffic, and scaling requirements.

≫ Want to understand the difference in depth, with PostgreSQL examples? Read the full blog.

🔦 Tech Spotlight!

Welcome to Tech Spotlight where we bring to you an interesting read from the industry.

In this week’s Tech Spotlight, we feature an article from the SerpApi team talking about reverse engineering Protobuf schema.

➥ Decoding Protobuf Messages Without Access to the Schema

Protobuf is a serialization/de-serialization format developed by Google. Unlike JSON, working with Protobufs requires access to a schema. Without a schema, you can’t pinpoint the keys and thus can’t use the payload.

The engineers at SerpApi demonstrate how to inspect wire types and reconstruct field structures directly from raw payloads. A fascinating real-world example of modern reverse engineering!

That brings us to the close of this episode! If you enjoyed reading it, consider dropping in a ❤️ below and leaving a comment.

But microservices aren’t that easy. They come with their own set of challenges, like ~

• How would one microservice discover another microservice?

• How do we ensure that failures in one microservice are contained and do not propagate to other services?

• …

We discuss the solution to the first two questions in this 12th episode of the System Design Weekly!

In this edition, we bring to you another interesting read from Netflix’s Engineering team talking about how they re-designed their notification system.

So, if that all sounds interesting to you, read on!

🧐 Service Discovery in Microservices

Unlike monolithic applications, services in a microservice architecture are typically deployed on separate machines. Thus, any communication between two services must be routed over network. And to do so effectively, services should know each other’s network addresses i.e., IP address, port number, transport mechanism, etc.

Since services are dynamically created/deleted, and moved around the cluster, we cannot maintain a hardcoded list of addresses for each service. Thus we need a mechanism for Service Discovery.

Service Registry is the special database that maintains a list of available instances of microservices and their addresses. Services refer to the service registry when they need to resolve address for a target service.

Several tools and platforms offer service discovery capabilities, each with its own set of features and trade-offs.

• Netflix Eureka: A REST based service registry.

• Kubernetes: Kubernetes offers built-in service discovery and load balancing capabilities through its service abstraction.

• Consul: Developed by HashiCorp, Consul provides service discovery, configuration, and segmentation functionalities on a single, distributed platform.

🔌 Circuit Breaker Pattern

Ever wondered how large-scale microservices keep a simple failing service from taking down the entire app? They look at electrical engineering.

Just like an MCB (Miniature Circuit Breaker) in our home breaks the circuit during a short-circuit to protect our appliances, the Circuit Breaker design pattern disconnects a failing microservice to prevent the issue from cascading.

Instead of blindly retrying and exhausting critical application resources (like database connections or memory) on a service that is already struggling, a circuit breaker acts as a proxy and manages the traffic using three simple states ~

• Closed State: Everything is normal. Requests flow freely while the breaker monitors for failures. If failures cross a specific threshold, it trips into the Open State.

• Open State: The breaker immediately cuts off traffic and returns a fallback response or exception. This gives the struggling service a “timeout” period to recover without being bombarded.

• Half-Open State: Once the timeout expires, the breaker allows a limited number of test requests through. If they succeed, it goes back to Closed. If they fail, it snaps back to Open.

  

≫ Read my full deep dive on Circuit Breakers on Medium

🔦 Tech Spotlight!

This week in Tech Spotlight, we’re featuring an interesting read from Netflix’s engineering team. The article explores how they re-designed their notification system to ensure better, more useful notifications for their customers.

➥ Thinking Fast and Slow: Netflix’s Notification Architecture

They presented a two paced system, where the slow-path is responsible for capturing the long-term notification strategy and the fast-path is responsible for deciding exact notifications.

If you are looking for a digestible version of Netflix’s article, checkout this commentary on System Design Weekly. 👇

That brings us to the close of this episode! If you enjoyed reading it, consider dropping in a ❤️ below and leaving a comment.

See you next week in yet another release of System Design Weekly! Till then, happy learning!

Notifications are an integral part of any application in 21st century. Whether they are mobile notifications or email notifications, they play a critical role in keeping the user engaged and updated on application’s status.

When compared to other parts of application engineering, sending out notifications may not sound like an engineering feat. But that is where most of us are wrong!

Behind every pop-up, there is hours of planning & thinking involved.

Netflix is no exception. To keep their users hooked, they too use notifications. And the way their system shows these notifications reveals a lot about the insane engineering that goes beind the scenes at these big techs.

In this blog, we are going to dissect the “Thinking Fast & Slow for a Personalized Notification System” blog by the Netflix Engineering team. The goal is to make the content easy to follow and offer a commentary around the complex parts of it.

👉 Original Netflix's Blog

Art of Optimizing the Notifications @ Netflix

Netflix sends out hundreds of millions of personalized notifications to its user in the form of push messages, in-app notifications, and emails. The goal is to help user discover the content that they would watch.

But there is an optimization problem. If they send too many notifications to a user, this can lead to fatigue and can lead to user turning off the notifications.

On the other hand, if there are too few notifications, the user won’t discover relevant content and can result into reduced app usage or stop being a member altogether.

Understanding the Existing Solution and the Problems with it

The previous notification system at Netflix used a short-time horizon model. The model was trained to optimize short-horizon metrics such as immediate user actions occuring shortly after notification is sent.

There were two problems with this model ~

(1) The model only considers short-term metrics but not long-term viewing habits. This can result in gradual opt-out risks.

(2) Both the “When” & “What” were coupled into a single system.

The old system seems to have worked like this ~

• A notification opportunity arises (for example a new show release)

• The model estimates the reward/value of sending that notification right now

• If the score exceeded some threshold, send it

This means that the frequency of notification was a by-product of these daily decisions. From my reading of the blog, it seems that the frequency was not a first-class citizen of the system. Increasing the threshold would reduce the frequency and that seems to be the only way of controlling frequency.

(3) Users are likely to behave differently based on the time of notification. Such personalization was also missing from the system.

To solve all these problems, a new system was built. A system where long term planning can be separated out from short term notification decisions. And this brings us to the “Slow-Fast Architecture”.

Hierarchical Slow-Fast Architecture

The entire notification service is broken into two separate modules — The Planner (Slow) and The Executor (Fast).

In a nutshell, the slow path is responsible for planning the frequency for each user based on their activity while keeping a long-time view of the things.

On the other hand, the fast path is responsible for selecting what message to send while respecting the frequency & timing guard-rails placed by the slow path.

The table below summarizes both modules.

Slow Policy

Slow policy works by selecting an action 𝒜. An action is nothing but a frequency plan across all channels that a user can be notified from.

There are over 100 hard-coded actions which the slow policy chooses from.

The selection of action is based on a utility function. The action which maximizes the utility for a member is choosen.

The details of this utility function is extremely vague in the blog and readers are left to guess a number of things around it. I will be presenting what I think would be going behind the scenes.

I have broken down the utility function as per my understanding in the diagram above.

There are two cruicial parts to it — (1) Estimating the reward from each action for a member, and (2) Estimating the cost from each action.

While the blog skip details about the first part, the second part is calculated by assuming a constant cost per notification. Interestingly, this cost is tuned manually!

For the first part, there must either be some model to estimate the reward or they must gather that information by running some experiments.

Note: To solve the problem of personalized notification timings, the slow policy also includes a pacing strategy in the plan it develops. No details on how the pacing strategy is calculated is present in the blog!

Fast Policy

Based on the frequency & timing constraints developed by the slow policy, the fast policy works. At every opportunity of sending a notification, the policy checks if the opportunity aligns with the plan developed by the slow policy and if so, it sends out a notification.

Benefits of the New Architecture

With the new architecture in place, Netflix engineers were able to solve all the problems they were facing with the old system. In addition, the new model gave them the following advantages ~

• They were able to give users a consistent experience since the system no longer only took a short-term view.

• With decoupling of the slow and the fast policy, it is easy to modify “When” & “What” of the notification system independently.

• With reduced noise, they saw much more engagement from casual users.

With that we come to the end.

If you would like to see more such blog dissection directly in your inbox, do subscribe and join the newsletter.

Subscribe now

1. Redis

The “Swiss Army Knife” of Key-Value Stores

If you don’t know what to pick, you usually pick Redis. But be careful. Interviewers love to ask why you picked it over Memcached. Redis is an in-memory data structure store, meaning it doesn’t just store strings but also it understands lists, sets, and hashes.

• What is it? In-memory, single-threaded (mostly), sub-millisecond latency store.

• Key Features: Persistence (RDB/AOF), Pub/Sub, Lua scripting, Geospatial support.

Use this when:

• You need complex data structures (Leaderboards with Sorted Sets).

• You need persistence (you don’t want to lose the cache on restart).

• You are building a rate limiter or a job queue.

Don’t use this when:

• You need multi-threaded performance (see Memcached).

• Your dataset is larger than RAM (though Redis on Flash exists, it’s not the default).

2. DynamoDB

The “I Don’t Want to Manage Servers” One

Amazon’s answer to “How do we make sure this never goes down?”. It’s a fully managed, serverless key-value and document database that delivers single-digit millisecond performance at any scale.

• What is it? A managed, serverless, distributed NoSQL database. Uses a B-tree under the hood (mostly).

• Key Features: Infinite scaling (literally), integrated with AWS IAM, Streams for event-driven architecture.

Use this when:

• You are in an AWS ecosystem (obviously).

• You need predictable performance regardless of scale (1GB or 1PB, it behaves the same).

• You need a “Shopping Cart” or “User Profile” store that handles millions of TPS.

Don’t use this when:

• You need complex joins or aggregations.

• You are on a tight budget (provisioned throughput can get pricey if you miscalculate).

3. FoundationDB

The “ACID Compliant” Distributed Beast

Apple bought this company for a reason. FoundationDB is unique because it provides ACID transactions across a distributed cluster. Most NoSQL DBs give up consistency for availability (AP in CAP theorem), but FoundationDB fights for Consistency.

• What is it? A distributed, ordered key-value store with strong ACID guarantees.

• Key Features: The “Onion” architecture. The core is a KV store, and you build “Layers” (like SQL or Graph) on top of it.

Use this when:

• You need strict correctness (financial transactions) but on a distributed scale.

• You want to build your own database on top of a reliable engine.

Don’t use this when:

• You need a simple cache.

• You want a “batteries included” database with a query language like SQL out of the box (unless you use a Layer).

4. Cassandra

The “Write Heavy” Heavyweight

Okay, technically this is a “Wide-Column Store,” but in system design, we often treat it as a KV store where the value is a map of columns. It’s famous for being used by Facebook and Instagram.

• What is it? A masterless, distributed database optimized for heavy writes.

• Key Features: Tunable Consistency (you can trade accuracy for speed), Peer-to-Peer architecture (no single point of failure), LSM Trees for fast writes.

Use this when:

• You have a write-heavy workload (e.g., storing Discord chat logs or IoT sensor data).

• You need high availability (AP) and can tolerate “Eventual Consistency.”

Don’t use this when:

• You need ACID transactions.

• You need frequent updates/deletes (Cassandra hates tombstones).

5. Riak DB

The “Amazon Dynamo” Sibling

Riak is an implementation of the famous Amazon Dynamo paper. It focuses purely on availability. If a node goes down, Riak doesn’t care. It just lets a neighbor handle the write.

• What is it? A distributed, decentralized key-value store.

• Key Features: CRDTs (Conflict-free Replicated Data Types) to handle merge conflicts automatically.

Use this when:

• Your system MUST remain available even if half the data center burns down (e.g., Shopping Carts).

• You are dealing with network partitions often.

Don’t use this when:

• You need strong consistency.

6. Etcd

The “Brain” of the Cluster

If you’ve used Kubernetes, you’ve used Etcd. It’s not for storing user data; it’s for storing the state of your system.

• What is it? A strongly consistent, distributed key-value store. Uses the Raft consensus algorithm.

• Key Features: Watch API (clients get notified when keys change), Lease primitives.

Use this when:

• Service Discovery (who is the leader?).

• Storing configuration data for a distributed system.

• Distributed locking.

Don’t use this when:

• You want to store large amounts of data. It has a tiny storage limit (usually a few GBs).

7. RocksDB

The “Embedded” Speedster

This is not a database server you connect to. It’s a C++ library you embed in your application. It was built by Facebook (forked from Google’s LevelDB) to exploit the full potential of fast storage like SSDs.

• What is it? An embeddable persistent key-value store based on Log-Structured Merge (LSM) trees.

• Key Features: Insane write throughput, tunable trade-offs (Space vs. Read vs. Write amplification).

Use this when:

• You are building a database engine (CockroachDB and MySQL MyRocks use RocksDB under the hood!).

• You need local, persistent, fast storage on a single node.

Don’t use this when:

• You need a networked database server.

• You need multi-machine replication out of the box.

8. LevelDB

The “OG” Embedded Store

Created by Jeff Dean and Sanjay Ghemawat at Google. It’s the predecessor to RocksDB. It’s simpler but single-threaded in some critical areas.

• What is it? A fast key-value storage library providing an ordered mapping from string keys to string values.

• Key Features: Snappy compression, simple architecture.

Use this when:

• You need a lightweight embedded store for a browser (Chrome uses it for IndexedDB) or mobile app.

Don’t use this when:

• You have high-concurrency server workloads (use RocksDB instead).

9. Memcached

The “Old School” Cache

Before Redis took over the world, Memcached was King. It is still widely used by giants like Meta because of its simplicity and multithreaded architecture.

• What is it? A high-performance, distributed memory object caching system.

• Key Features: Multithreaded architecture (scales well on big CPUs), extremely simple Key-Value model.

Use this when:

• You need raw, simple caching power and have vertical scaling needs (multithreading).

• You cache small, static objects (HTML fragments, session data).

Don’t use this when:

• You need persistence (if you restart, data is gone).

• You need advanced data types (Lists, Sets).

Till next time, happy learning!

If you have tackled concurrent programs, you would know that such programs can fail in ways that defy traditional logic. In this edition, we are going to discuss one such issue. We call it Cache Line Bouncing or False Sharing. You will find out how multiple cores and caches cause performance issues that just don’t exists in single threaded environments.

While at the topic of CPU usage optimizations, we also discuss Flame Graphs. These graphs are designed specifically to analyze call stacks, quickly revealing hot paths and wasted cycles. If you find yourself debugging CPU issues at very low levels, a Flame Graph is the essential tool to have in your toolbox.

And before we bid adieu, we share an amazing writeup from the Netflix Engineering team that talks about how they fixed a container scaling issue on AWS nodes.

So, if that all sounds interesting to you, read on!

🦘 Cache Line Bouncing (aka False Sharing)

For a CPU to operate on any data, that data must first be loaded into its registers. To reach the registers, data typically moves from main memory and passes through the cache hierarchy, starting with the L3 cache, then the L2 cache, and then the L1 cache, before finally being loaded into the registers. Once the data is in the registers, the CPU can read or modify it. Any modifications are eventually propagated back to lower level caches and ultimately to main memory according to the cache coherence and write back policies.

When the CPU fetches data from memory, it does not load only the requested bytes. It also brings in nearby bytes. This behavior is a direct consequence of the Locality of Reference principle.

Locality of Reference is a fundamental principle stating that programs tend to repeatedly access a small set of memory locations over short periods, which is key to effective caching.

It has two forms:

• Temporal locality: recently accessed data is likely to be accessed again soon (e.g., loop variables).

• Spatial locality: accessing one memory location increases the likelihood of accessing nearby locations (e.g., array iteration).

Because of this, cache entries do not store individual variables, pointers, or objects. Instead, the CPU cache is organized into fixed size blocks of bytes called Cache Lines, typically 64 or 128 bytes in size.

A Java long is 8 bytes, so in a single cache line you could have 8 long variables.

Now comes the interesting part… If two variables accessed by different CPU cores are placed in memory such that they reside on the same cache line, they will be fetched and updated together. This can lead to subtle and serious performance problems.

When data accessed across cores happens to fall into a single cache line, access to a cache line by any one processor will expire the cache of any other processor holding that same line. This causes every context switch to fetch the cache line again. This exact situation is described as the Cache Line Bouncing.

A standard way of fixing this is to ensure that variables accessed across cores are not part of the same cache line by adding sufficient padding between them.

🔥 Flame Graphs

Flame graphs are a visualization tool for performance profiling that helps identify which code paths consume the most CPU time.

In words of Brenadan, this is how you can read a flame graph.

• Each box represents a function in the stack (a “stack frame”).

• The y-axis shows stack depth (number of frames on the stack). The top box shows the function that was on-CPU. Everything beneath that is ancestry. The function beneath a function is its parent, just like the stack traces shown earlier. (Some flame graph implementations prefer to invert the order and use an “icicle layout”, so flames look upside down.)

• The x-axis spans the sample population. It does not show the passing of time from left to right, as most graphs do. The left to right ordering has no meaning (it’s sorted alphabetically to maximize frame merging).

• The width of the box shows the total time it was on-CPU or part of an ancestry that was on-CPU (based on sample count). Functions with wide boxes may consume more CPU per execution than those with narrow boxes, or, they may simply be called more often. The call count is not shown (or known via sampling).

• The sample count can exceed elapsed time if multiple threads were running and sampled concurrently.

🔦 Tech Spotlight!

In this week’s Tech Spotlight, we bring to you an engineering masterpiece from Netflix engineering team.

➥ Mount Mayhem at Netflix: Scaling Containers on Modern CPUs

In this blog, Netflix engineers talk about the delay they noticed when trying to start 100s of container at once. Their investigation dives deep into several fascinating topics, including OverlayFS, Cache Line Bouncing, and Kernel ID Mapping. While the content is technical, it’s an eye-opening read, and once you dig in, you’ll be in awe of the insights shared.

That brings us to the close of this episode! If you enjoyed reading it, consider dropping in a ❤️ below and leaving a comment.

See you in the next edition of the System Design Weekly! Till then, happy learning!

In this edition of the newsletter, we have an interesting topic in focus - the N+1 problem. This is a common performance bottleneck that many data intensive application face, particulary the ones using some sort of Object Relational Mapping (or ORM for short).

For this edition’s Tech Spotlight, we have an awesome blog from Atlassian’s engineering team covering how they scaled Jira export service using a streaming architecture.

🚨The N+1 Problem in Software Engineering

An Object-Relational Mapping (ORM) is a software tool or technique that creates a conceptual “bridge” between the structure of a relational database (like tables, rows, and columns) and the object-oriented concepts used in modern programming languages (like classes, objects, and properties).

When database tables have relationships (like one-to-one, one-to-many, etc.), ORMs have a special way of loading the data for related objects.

😴 Lazy Loading

Imagine you have two related objects, A and B. When you load object A, the ORM generally doesn’t load object B immediately. This is called lazy loading.

• It saves a database trip if you only need object A.

• The ORM puts a placeholder for B inside A.

• If you later try to access object B through A, the ORM makes a second database call right then to fetch B.

💥 The N+1 Problem

Lazy loading is usually good for performance, but it can cause problems when you need all related objects at once, like listing many As and their associated Bs.

• The ORM first runs one query to get all N objects of type A.

• Then, as you loop through these N objects and ask for their related B, the ORM runs one separate query for each object A to get its B.

• This results in N + 1 total queries (1 for all A’s + N individual queries for all B’s), which is very slow. This is known as the N+1 query problem.

Most modern ORMs offer methods to avoid this, like eager loading (fetching all related data in one or two efficient queries upfront).

» If you would like to know more about tackling N+1 problem in Java, checkout our Medium blog!

🔦 Tech Spotlight!

Optimizing application’s performance is both an exciting and challenging endeavor. In this edition of Tech Spotlight, we feature an insightful piece from the Atlassian Engineering blog that talks about performance optimization of Jira export.

➥ Boosting Performance: How We Scaled and Enhanced Throughput in the Jira Export Service

The article dives deep into the architecture of the Jira export service and how a major architecture rehaul was required to eliminate the bottlenecks. The author also delves into the code-level optimizations, particularly solving the N+1 query problem, that significantly reduced latency.

Definitely a must read for system architects, backend developers, and anyone with a curiosity to learn!

And that is it for this edition! If you enjoyed what you read, consider clicking the ❤️ button below and leaving a comment.

See you in the next edition of the System Design Weekly! Till then, happy learning!

Stack Overflow is one of the most underrated source of knowledge for developers. Threads, almost as old as 20 years, contain wisdoms & advice from great developers. Following those wisdoms alone will make anyone a 2x developer!

Over the course of my software development journey, I too have learnt & picked a lot of things from this amazing site.

In this post, I would like to share some of the things in my .bashrc that I have their origin straight from SO and seriously impacted (in a positive way) the way I code & develop.

Delete Files in Terminal Safely

Familiar with rm -rf? Yes, the command that deletes files and folder FOREVER!

Once it is used on a file/folder, there is no going back.

You know how easy it is to fat-finger a command? You mean to wipe just the current folder with rm -rf ./*, but you miss the dot and type rm -rf /* instead. Boom! Now you’re aiming at the whole filesystem. All from one tiny typo. Yikes.

In your bashrc, you can add the following alias to always use option -i with rm command.

alias rm=’rm -i --preserve-root’

The -i option makes rm prompts for every file it is about to delete and --preserve-root ensures that you can never delete /.

Another less intrusive way of ensuring safety is to use the -I option.

alias rm=’rm -I --preserve-root’

The man page of rm describes the -I option as follows ~

Request confirmation once if more than three files are being removed or if a directory is being recursively removed. This is a far less intrusive option than -i yet provides almost the same level of protection against mistakes.

With this small alias in your bashrc, you can always be confident of any rm commands that you run!

Tired of cd ../../../../../ ?

When trying to move up multiple directories at once, we use the cd command as cd ../../../../... This is both time-taking and error-prone.

At least, I often find myself over-stepping or under-stepping directories, requiring an extra cd command to reach the current position.

To solve this exact pain point, you can add a convenient up function in your bashrc.

up() { cd $(eval printf ‘../’%.0s {1..$1}) && pwd;}

Once sourced, you can use the up function to conveniently move up directories.

❯ cd projects
❯ up 3
/
❯

This small utility can help you move around your filesystem much quickly!

Create Directory and Switch to it in one step

I always wonder why there isn’t a famous CLI tool that creates a directory and switch to it in a single go.

Luckily, it is not that difficult to write your own bash function to achieve this.

md() {
  mkdir “$1” && cd “$1”
}

And with that, we have our own method to create and change directory at once!

A function that extracts anything?

If you are not a terminal wizard, chances are that anytime you need to unpack a compressed file, you refer to the internet.

I found this amazing function that can be used to extract a number of file types. (Source)

extract() {
    local archive_file=”$1”
    local extract_dir=”$2”

    # Check if an archive file is provided
    if [[ -z “$archive_file” ]]; then
        echo “Usage: extract <archive_file> [extract_directory]”
        return 1
    fi

    # Determine the extraction directory
    if [[ -z “$extract_dir” ]]; then
        extract_dir=”.”
    fi

    # Ensure the archive file exists
    if [[ ! -f “$archive_file” ]]; then
        echo “Error: File ‘$archive_file’ not found.”
        return 1
    fi

    # Get the file extension
    local extension=”${archive_file##*.}”
    local base_name=”${archive_file%.*}”

    # Use a case statement to handle different archive types
    case “$archive_file” in
        *.tar.gz|*.tgz)
            echo “Extracting $archive_file to $extract_dir...”
            tar -xzf “$archive_file” -C “$extract_dir”
            ;;
        *.tar.bz2|*.tbz2)
            echo “Extracting $archive_file to $extract_dir...”
            tar -xjf “$archive_file” -C “$extract_dir”
            ;;
        *.tar.xz|*.txz)
            echo “Extracting $archive_file to $extract_dir...”
            tar -xJf “$archive_file” -C “$extract_dir”
            ;;
        *.tar)
            echo “Extracting $archive_file to $extract_dir...”
            tar -xf “$archive_file” -C “$extract_dir”
            ;;
        *.zip)
            echo “Extracting $archive_file to $extract_dir...”
            unzip -q “$archive_file” -d “$extract_dir”
            ;;
        *.rar)
            echo “Extracting $archive_file to $extract_dir...”
            if command -v unrar &> /dev/null; then
                unrar x -o+ “$archive_file” “$extract_dir/”
            else
                echo “Error: ‘unrar’ command not found. Please install it.”
                return 1
            fi
            ;;
        *.7z)
            echo “Extracting $archive_file to $extract_dir...”
            if command -v 7z &> /dev/null; then
                7z x “$archive_file” -o”$extract_dir”
            else
                echo “Error: ‘7z’ command not found. Please install it.”
                return 1
            fi
            ;;
        *.ar)
            echo “Extracting $archive_file to $extract_dir...”
            if command -v ar &> /dev/null; then
                ar x “$archive_file” “$extract_dir/”
            else
                echo “Error: ‘ar’ command not found. Please install it.”
                return 1
            fi
            ;;
        *.cpio)
            echo “Extracting $archive_file to $extract_dir...”
            if command -v cpio &> /dev/null; then
                cpio -idm -D “$extract_dir” < “$archive_file”
            else
                echo “Error: ‘cpio’ command not found. Please install it.”
                return 1
            fi
            ;;
        *)
            echo “Unsupported archive format for ‘$archive_file’.”
            return 1
            ;;
    esac

    # Check if the extraction was successful
    if [[ $? -eq 0 ]]; then
        echo “Successfully extracted ‘$archive_file’ to ‘$extract_dir’.”
        return 0
    else
        echo “Error during extraction of ‘$archive_file’.”
        return 1
    fi
}

With this function added to your bashrc, you can use it as follows ~

extract my_archive.tar.gz

# Extracting to a specific directory
extract my_document.zip /path/to/destination/folder

extract backup.rar

extract software.7z

Jump to the root of git repo

Another interesting bash function that I have kept in my bashrc is the gr. It helps me jump to the root of the working tree from anywhere inside a git repo.

Following is the function that achieves this!

gr() {
  cd “$(git rev-parse --show-toplevel 2>/dev/null)” || echo “Not in a git repo”;
}

Rerun last command as sudo

Ran a command only to see it failing because it has not been run with sudo?

One option is to use the sudo !! to run the last command with sudo, or, you can create an alias (like me) to run the last command as sudo!

Add the following to your bashrc.

alias please=’sudo !!’

And, use the please command to run the last command with sudo!

Find files by name

The find is a powerful command that is used for searching through files and folders recursively. With its variety of options and configurations, it can be used for a number of find tasks.

But this level of customization comes with its own cons. Sometimes, for doing simple things, such as finding files by name, you have to remember the right options or look them up online.

Additionally, searching file by name is a common operation that can be added as a function in your bashrc.

ff() { [ -n “$1” ] && find . -type f -iname “*$1*”; }

Once this function is added in your bashrc, you can use it to find files in any directory (and its sub-directories recursively).

Use bat instead of cat

The cat command is one of the most popular commands developers use.

The bat tool is a clone of famous cat program with support for syntax highlighting and git integration.

You can simply create an alias for bat like the following and you will supercharge your cat command!

alias cat=’bat --paging=never’

With this we reach the end of this article.

Did you happen to already use any of these gems? Or, does anything here got your attention that you will start using it? Do let us all know in the comments!

If you enjoyed reading this piece, drop a clap and do follow me for more such interesting reads.

Until next time, happy reading!

Originally posted on Medium.

Based on Google’s seminal Bigtable white paper, this episode unpacks how Bigtable powers massive-scale applications like Search, Maps, and Gmail—and how it inspired a generation of NoSQL systems like HBase and Cassandra.

We break down Bigtable’s core design, including its data model, SSTables, memtables, and the tablet-based architecture that allows it to scale horizontally across thousands of machines. We also explore how Bigtable achieves consistency and fault tolerance using technologies like the Google File System (GFS) and Chubby.

Whether you're building distributed systems yourself or simply curious about how planet-scale data infrastructure works, this episode will give you a solid foundation in one of the most impactful systems in modern computing.

Tune in to learn how Bigtable balances performance, scalability, and reliability at a truly massive scale.

P.S. AI was used to record this podcast.

When I first started building web apps, “authentication” just meant logging in. Simple, right?

But then came questions — What’s a token? Should I use cookies or API keys? Why are there so many options just to verify a user?

Turns out, each method has a purpose. Some are outdated, some are secure, and others are great for specific use cases.

In this blog, I’ll break down six common authentication methods — Basic Auth, Cookies, Tokens, API Keys, OTP, and SSO — and explain when (and why) to use each.

Let’s get started.

Subscribe now

Basic Authentication

Basic authentication works by sending the encoded username and password to the server with every request. These credentials are included in the request headers.

The username and password are combined into a single string and encoded using Base64. This encoded string is then sent in the Authorization header of the HTTP request.

Basic Authentication is one of the oldest authentication mechanism that dates back to 1990s.

While Basic Authentication is simple and efficient, it is not very secure, as the credentials are merely Base64-encoded — making them easily reversible. This leaves it vulnerable to man-in-the-middle attacks, especially when used over an insecure protocol like HTTP.

There is also no easy way to log out a user through the server.

Even with a secure protocol underneath, basic authentication can suffer from CSRF attacks. Because of these reasons, most of the modern web applications have moved away from it in pursuit of safer authentication mechanisms.

Cookie-Based Authentication

Cookie-based authentication works by generating a session ID when the user logs in, which is then stored as a cookie in the user’s browser. For subsequent requests, the browser automatically includes this cookie, allowing the server to verify the user’s identity.

The generated session ID is given an expiry time to ensure that a single cookie cannot be used for infinity.

Cookie-based authentication improves upon Basic Authentication by allowing the server to manage user sessions. This enables features like server-side logout, where a user can be forcibly logged out by invalidating their session on the server.

Modern browsers offer several mechanisms to help protect cookies from security threats such as Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF). Features like the HttpOnly, Secure, and SameSite cookie flags help reduce these vulnerabilities.

However, cookie-based authentication isn’t without drawbacks. Session data must be stored on the server, which consumes resources and may not scale easily. Additionally, cookies are primarily designed for web browsers and are not well-suited for other types of clients, such as mobile apps or APIs.

Token-Based Authentication

In this authentication method, the server responds to a user’s login request by issuing a token. The token is self-contained, meaning it carries all the information needed for verification, and it’s designed to be tamper-proof.

In token-based authentication, the server doesn’t need to store any session data — only a public key (if using signed tokens like JWTs) to verify the token provided by the client. This contrasts with session-based authentication, where the server must maintain session state.

Once the client obtains a token, it can include it in the request headers to make authenticated requests. This makes token-based authentication stateless and well-suited for scalable, distributed systems.

Applications using token-based authentication are simpler to scale and can support a wide variety of clients.

The most popular token based authentication is Json Web Tokens (or JWT).

There are some downsides as well. If tokens are not securely stored on the client side, they can be stolen and used to impersonate the user. Additionally, tokens — especially those containing payload data like JWTs — are typically larger in size compared to other authentication mechanisms, leading to slightly higher bandwidth usage.

API Key-Based Authentication

API key-based authentication is a method for authenticating users or applications accessing an API (Application Programming Interface).

An API key is a unique identifier (usually a long alphanumeric string) issued to a developer or application to access an API. It acts as a simple access token, identifying the calling project or app.

API keys are issued when developers register with an API provider and request access. These keys are typically associated with specific projects and can be configured with varying levels of access control. API providers use them to monitor usage and enforce rate limits, often for billing, analytics, or security purposes.

There are several different ways in which a client can send an API key to the server -

1. HTTP Header — Authorization: Api-Key <your_api_key> or x-api-key: <your_api_key>

2. Query Parameter — https://api.example.com/data?api_key=<your_api_key>

3. Request Body (for POST requests) — { "api_key": "<your_api_key>" }

OTP Based Authentication

Another widely used authentication method in modern software applications is OTP-based authentication (One-Time Password). Unlike traditional fixed passwords, OTP authentication relies on a unique, time-sensitive code that is valid for only one login session or transaction.

When a user attempts to log in, the server generates a one-time password with a short expiry window (typically 30 seconds to a few minutes). This OTP is sent to the user via a trusted, pre-verified channel — such as a registered mobile number (via SMS) or email address. The user must enter the correct OTP to complete the login process.

This method adds an additional layer of security by:

• Reducing the risk of password reuse and phishing attacks

• Ensuring that only the rightful user (with access to the trusted device/email) can log in

Once the OTP is verified and the user is successfully authenticated, the system typically issues a session token or cookie to maintain the user’s authenticated state for the duration of the session. This token is then used for subsequent requests, avoiding the need to re-enter credentials repeatedly.

🔐 OTP authentication is often used as a form of two-factor authentication (2FA) when combined with a traditional password, further strengthening account security.

Single Sign On (SSO)

Single Sign-On (SSO) is a way to let users log in just once and then access multiple apps or systems without having to log in again each time. After the user signs in through the SSO provider, a token is created and passed to other trusted services, so the user can move between them smoothly without being asked to enter their credentials again.

Here is how it works

• The user visits the website and tries to log in.

• The website checks if the user is already logged in through the presence of some tokens or cookies. If it is, the request is processed.

• If not, the user is redirected to the SSO login page.

• The user logs in through the SSO system.

• SSO verifies credentials with the identity provider (e.g., Active Directory).

• Upon successful verification, SSO sends authentication info to the website.

• The website grants access and uses tokens/cookies to maintain authentication across other apps or pages.

Article originally posted here.

Software comes in many forms, built with diverse tech stacks and designed to meet various functional and non-functional requirements. That’s why there’s no universal approach to testing. In fact, the industry uses over 100 different testing methods. Today, we’ll explore 20 of the most popular ones.

In this week’s Tech Spotlight, we present yet another article by DropBox’s engineering team discussing how & why they built their in-house Load Balancer called Robinhood.

Subscribe now

🧪 20 Ways for Software Testing

Software testing can be classified across three dimensions: by level, by purpose, and by execution method, with additional specialised types for targeted use cases.

🪜Tests by Level

1. Unit Testing: Tests individual components (functions, classes). Written by developers. Fast and automated.

2. Integration Testing: Ensures modules work together properly. Written by devs and QAs.

3. System Testing: Tests the full, integrated application. Managed by QAs. Covers end-to-end workflows.

4. Acceptance Testing: Verifies business requirements are met before release. Often done by Solution Architects.

🎯 Tests by Purpose

1. Regression Testing: Ensures old functionality still works after updates.

2. Smoke Testing: High-level check after build/deploy to ensure critical functionality works.

3. Functional Testing: Verifies specific software features behave as expected (black-box).

4. Sanity Testing: Quick checks after minor changes to ensure stability.

5. Exploratory Testing: Manual, unscripted testing to find unexpected issues.

6. Non-Functional Testing: Focuses on performance, scalability, security, and usability.
   Includes: Performance, Load, Stress, and Security Testing

⚙️ Tests by Execution

• Manual Testing: Performed by humans without automation.

• Automated Testing: Uses scripts/tools to run and verify tests efficiently.

🧩 Specialised Tests

• Black-Box Testing: Focuses on inputs/outputs, no internal knowledge.

• White-Box Testing: Tests internal code and logic.

• Grey-Box Testing: Combines limited internal knowledge with external testing.

• A/B Testing: Compares different versions to measure performance.

• Performance Testing: Measures system responsiveness under load.

  • Load Testing: Under expected usage.

  • Stress Testing: Beyond normal limits.

• Security Testing: Detects vulnerabilities and ensures system safety.

» Looking for a deep-dive? Checkout my blog on Medium!

🔦 Tech Spotlight!

If you're familiar with load balancers, you know they're designed to distribute traffic evenly across multiple servers. One common approach is the round-robin algorithm, which cycles through servers to allocate requests uniformly. But what happens when your servers don't have equal capacity? Not every machine can handle the same amount of load.

This was the exact challenge faced by engineers at DropBox, prompting them to create a custom load balancer called Robinhood.

➥ Robinhood - The in-house load balancing service

The article talks about what challenges they faced before Robinhood and how they made sure that the new load-balancer is scalable and fault tolerant!

Certainly an interesting read for System Design enthusiasts!

And that is it for this edition! If you enjoyed what you read, consider clicking the ❤️ button below and leaving a comment.

See you next week in yet another release of System Design Weekly! Till then, happy learning!

Designed to ensure consistency across distributed databases, 2PC is a coordination protocol that helps multiple systems agree on a transaction's outcome—even in the face of network failures or crashes.

In this episode, we break down why 2PC is necessary, how it works step by step, and the trade-offs that come with using it. We also take a look at how technologies like ZooKeeper are commonly used to implement 2PC in real-world systems.

As one of the more approachable distributed algorithms, Two-Phase Commit is a great entry point for engineers beginning their journey into the world of distributed systems.

Tune in and get a clearer understanding of consistency, coordination, and the challenges of building reliable distributed software.

P.S. AI was used to record this podcast.

In this week’s Tech Spotlight, a fascinating article from Dropbox’s Engineering team dives into the challenges faced due to clock skews!

Subscribe now

*️⃣ 11 Rules for Regular Expressions

• Basic Literal Matching

  • Match exact sequences of characters.

  • Example: /helloWorld/ matches "helloWorld".

  • Special characters may need to be escaped with a backslash.

• Dot Wildcard

  • The dot (.) matches any single character, except for newline characters.

  • Example: /ca./ matches "car", "cap", "can", "cat".

• Anchors

  • Use anchors to match the start (^) or end ($) of a line.

  • Example: /^success$/ matches "success".

• Alternation

  • Use the pipe (|) to represent OR logic within a pattern.

  • Example: /coffee|tea|milk/ matches "coffee", "tea", or "milk".

• Groups & Parentheses

  • Group parts of the pattern using parentheses to capture or refer to them later.

  • Example: /(hello|hi)world/ matches "hello world" or "hi world".

• Character Classes

  • Match any one character from a defined set using square brackets [].

  • Example: /gr[ae]y/ matches "gray" or "grey".

  • Ranges like [0-9] match any digit, and [a-f] matches hexadecimal digits.

• Negated Character Classes

  • A caret (^) at the beginning of a character class negates it, matching any character not in the set.

  • Example: /[^a-z]../ matches "Cat", "Dog", or "Car".

• Quantifiers

  • Define the number of occurrences of a character or group.

  • Example: /^\+[0-9]?[0-9]{11}$/ matches valid phone numbers.

• Non-Capturing Groups

  • Use (?:...) to define a group without capturing it, improving performance.

  • Example: /^(?:hello) world$/ matches "hello world".

• Back References

  • Match the same text as a previously captured group using \1, \2, etc.

  • Example: /^([a-zA-Z]*)-\1$/ matches "boom-boom" or "Boom-Boom".

• Assertions

  • Assertions verify conditions before or after a match, without including them in the final match.

  • Example: /Alley(?=is cute)/ matches "Alley" but only if "is cute" follows.

» Checkout our Medium Blog for a deep-dive

🔦 Tech Spotlight!

At System Design Weekly, we’ve previously explored the challenges of clock skews, especially when it comes to getting them right in distributed systems. This week’s Tech Spotlight features a fascinating real-world case study from Dropbox, where clock skews led to unexpected bugs in their password manager.

➥ Fighting the forces of clock skew when syncing password payloads

Dropbox’s password management system stores passwords on client devices. Since users often have multiple devices (phone, tablet, laptop, etc.) connected to the same account, even a small clock skew can sometimes lead to lost updates. In this article, Dropbox’s engineers explain how they implemented a three-way merge strategy, similar to Git, to address this issue.

And that is it for this edition! If you enjoyed what you read, consider clicking the ❤️ button below and leaving a comment.

See you next week in yet another release of System Design Weekly! Till then, happy learning!

Back-of-Envelope calculations aren’t about pinpoint accuracy; rather, they allow you to estimate key factors like latency, storage requirements, and network bandwidth—often within the right order of magnitude.

Tune in to discover how these simple yet powerful calculations can help developers build better, more scalable software. Don't miss out—listen now!

P.S. AI was used to record this podcast.

As you read on, you will find a brief overview of various types of coding design patterns. Design patterns are often grouped based on their intent to enhance recognition and usability.

Towards the end, in this week's Tech Spotlight, we feature an article from Canva’s Engineering team on building a service designed to Count to a Billion!

✉️ Hinted Handoffs

Hinted Handoffs is a distributed database technique that enables database writes to be processed even when some nodes in the database cluster are unavailable.

Example~ In a three-node distributed database, the coordinator performs writes across all nodes and confirms success. If a node (e.g., Node A) goes down, the coordinator stores hints and delivers them once the node is back online.

Here are some interesting things about Hinted Handoffs ~

• Each node maintains a local hint storage.

• Logical clocks are used for event ordering with timestamps.

• Nodes gossip to share information and maintain a local view of other nodes' statuses.

• Hints usually don't count toward quorum in most systems.

• Databases with hint-replay manage replay rates to avoid overwhelming nodes.

Cassandra and DynamoDB are the two most popular examples of databases using Hinted Handoffs!

≫ Checkout our Medium Blog for a deep-dive into Hinted Handoffs

🏷️ Classification of Coding Design Patterns

Design patterns are proven solutions to common software development challenges that developers have encountered over time. These patterns provide best practices and guidance on how to structure and write code effectively, ensuring scalability, maintainability, and efficiency.

To simplify the study and application of design patterns, they are typically categorized into groups based on shared characteristics. Below, we explore the most common classification of design patterns into three main groups ~

Creational Design Patterns

Creational Design Patterns address the challenges of object creation, which may initially seem like a straightforward task. However, in large codebases with thousands of classes, complex relationships, and numerous parameters, the process of object creation becomes far more intricate. In such cases, carefully structuring and planning how objects are instantiated is crucial to maintaining scalability, flexibility, and ease of maintenance.

Some popular creational design patterns are Factory, Singleton, and Builder.

Structural Design Patterns

Structural Design Patterns address the challenges involved in composing large structures out of classes and objects. Using these patterns, it is possible to manage complex class hierarchies, reuse existing code, and create scalable architecture.

Some popular structural design patterns are Adapter, Proxy, and Facade.

Behavioural Design Patterns

Behavioural design patterns focus on defining algorithms and determining how responsibilities are distributed among objects.

Some popular behavioural design patterns are Chain of Responsibility, Strategy, and Visitor.

🔦 Tech Spotlight!

In this week’s Tech Spotlight, we feature an article from Canva’s Engineering team, where they dive into the design of their content usage counting service. The service must maintain exceptional accuracy at scale, as the content usage data directly impacts payouts to creators.

➥ Scaling to Count Billions

They’ve crafted their latest architecture by combining DynamoDB with an OLAP database to handle end-to-end usage data calculations. However, what I found most fascinating is not just the current design, but the evolution that led to it. It’s a must-read for anyone passionate about system design!

And that is it for this week! If you enjoyed what you read, consider clicking the ❤️ button below and leaving a comment.

See you next week in yet another release of System Design Weekly! Till then, happy learning!

In this week’s edition, we talk about an interesting topic called Logical Clocks. Clocks and timestamps are one of those things that are just so easy to reason in a centralised system but quickly become complex in distributed systems’ design. Specifically, we talk about Lamport Clocks and Vector Clocks here!

Next, we dive into one of the most essential topics in bash scripting—Exit Codes. These numerical indicators help us understand the result of executing a command, which can be used for debugging and building robust scripts. Whether you're a beginner or a seasoned scripter, understanding how exit codes work can elevate your workflow.

Finally, in this week's Tech Spotlight, we feature an insightful white paper from Amazon, diving into the design of its DynamoDB.

Subscribe now

⏰ Logical Clocks

First introduced by Lamport in 1978, logical clocks provide a method for capturing the order of related events in a distributed system using counters. The numerical value of a logical clock is independent of real-time, focusing solely on event ordering.

In a distributed system, each process starts with its own logical clock set to 0, which increments by 1 with each event it processes. When one process sends a message, it first increments its clock and includes the updated value in the message. Upon receiving the message, the receiving process increments its own clock by 1, compares it with the value in the message, and updates its clock to the maximum of the two values, ensuring correct event ordering.

Vector clocks are an extension to the Lamport clocks. Instead of maintaining a single counter, each process maintains a vector of numbers. The length of the vector is equal to the number of nodes in the distributed system. Each event is now timestamped with the entire vector V.

≫ A deep-dive into logical clocks soon releasing on our Medium Blog

🏃 Exit Codes in Bash

The exit code is an integer value returned by a Bash command or script upon its termination. These codes indicate the outcome of the program’s execution.

Generally, a non-zero exit code indicates unsuccessful execution of a program while an exit code of 0 denotes a successfully executed program.

The value of exit codes can range from 0 to 255 and some of these values hold special meaning and are more prominent than others. The table above summarises some of the most popular exit codes!

≫ Checkout the complete blog on System Design Weekly

🔦 Tech Spotlight!

Amazon's DynamoDB is a highly available and high-performance distributed key-value store. Initially developed for Amazon's internal use, it rapidly gained popularity as a top database solution after being made available to a broader audience through AWS.

In this week’s tech spotlight, we feature the white paper discussing the design of this amazing technology.

➥ Dynamo: Amazon’s Highly Available Key-value Store

The paper explores how key distributed database concepts such as Consistent Hashing, Hinted Handoffs, Sloppy Quorums, and Replication are leveraged to create a highly available system. It’s a must-read for all System Design enthusiasts!

And that is it for this week! If you enjoyed what you read, consider clicking the ❤️ button below and leaving a comment.

See you next week in yet another release of System Design Weekly! Till then, happy learning!

Whether you're a system designer, developer, or tech enthusiast, this episode provides valuable insights into the architecture behind one of the most influential databases in modern cloud computing.

Tune in to get a closer look at how Dynamo DB's design continues to influence the next generation of distributed systems. Don't miss out—listen now!

AI was used for recording this Podcast.

Databases often employ a number of specialised data structures to ensure high performance storage and retrieval of data. While there exists thousands of databases in the wild, there are only a handful of data structures powering them all!

In this blog post, we are going through 11 such data structures. We will talk about the features of that data structures, why & how they are used in database engines, and which famous databases use them internally.

Subscribe now

Let us get started then!

Hash Indexes

Hash indexing is a technique that uses an in-memory Hash Map to enable fast key lookups. Each key is hashed and mapped to a disk pointer, allowing the system to directly fetch the corresponding value with a single disk seek.

A big disadvantage of Hash indexing is the fact that the entire structure needs to be maintained in memory. If the number of keys is too large to fit in the memory, hash indexes won’t work!

Some of the famous databases that uses Hash Indexes includes ~

• Redis

• Postgres (Offers a persistent on-disk hash index)

Skip Lists

Skip list is a probabilistic data structure that provides efficient search, inserts, and delete in a sorted linked list. All the operations can be performed in O(log N) time compared to O(N) it takes in a simple linked list.

As shown in the illustration above, sparse levels of Linked List are created to assist in quick searches eliminating the need for a sequential search.

Because skip lists store data in sorted order, they are most commonly used in databases for managing Memtables, which we’ll discuss in the upcoming sections.

RocksDB is a great example of a database where Skip Lists are used as Memtables!

Inverted Indexes

Inverted indexes are a common tool for databases that support text based searches. It divides text into individual words and constructs a word to document ID index. This allow quick searches for document containing certain words or patterns.

Elastisearch database is the most popular example that uses inverted indexes to power its full-text search capabilities.

B-Trees

B-Tree is un-arguably the most popular data-structure when it comes to databases. It is a self-balancing tree structure that maintains sorted data on disk and allows searches in logarithmic time complexity.

The key feature of B-Tree is its ability to store more than one key inside a single node that essentially reduces the number of disk seeks.

Almost all relational databases use B-Trees!

• Postgres

• MySQL

Bloom Filters

Bloom filter is yet another probabilistic data structure that is used to test whether a data entry exists in the database before we actually start looking for it. The way Bloom filters are designed, they can give false positive but they can never give false negatives.

Bloom filters are most commonly used in LSM-Tree based databases where a non-existent key could lead the database to search all segments! Instead, if a bloom filter is used before going through the segments, the time taken to search for non-existent keys is improved drastically.

A good example of this case is Cassandra that uses bloom filters in read path to ensure non-existent keys can be responded to quickly!

MemTable

MemTable is an in-memory data-structures that is used to hold reads and writes until they are flushed to disk based SSTables (more on them in the coming section).

MemTable handles both read and write operations: new writes are always inserted into the memtable, while reads must query the memtable first before checking the SSTable files, as the data in the memtable is newer. When a memtable becomes full, it is marked as immutable and replaced by a new one. A background process then flushes the contents of the memtable to an SST file, after which the old memtable can be safely discarded.

There are several ways in which a MemTable can be implemented!

RocksDB and LevelDB are some examples of databases that uses a MemTable.

BitMap Indexes

BitMap indexes uses bitmaps (or, simply put, array of 0s and 1s) to efficiently store and query data. It is particularly useful for columns with low cardinality of distinct value set.

Bitmap indexes use a series of bits to represent the presence or absence of a value in each row. Each bit corresponds to a row in the table, and its value (0 or 1) indicates whether the row contains a specific value for the indexed column.

Databases use these bitmaps to run efficient queries using bitwise operations. It is much quicker to combine bitmaps using ANDs and ORs!

Many modern databases like Postgres provide support for BitMap indexes.

Sorted String Table or SSTable

Sorted String Table (SSTable) is a persistent file format that maintains sorted data. It is created using the data from in-memory MemTables and is then persisted on disk as immutable files.

Spare hash indexes are often used to ensure fast searches through SST Files.

SSTable and MemTable together forms the basis of LSM-Tree based databases that are commonly found in many NoSQL databases like Cassandra, ScyllaDB, and RocksDB.

Prefix Trees

Prefix Tree (or, as they popularly known as, Trie) is a data structure optimised to work with strings or text-based data. It creates a tree structure out of a text corpus and use it to perform efficient prefix searches.

Databases like Elasticsearch use Trie for building their inverted index structures.

Write Ahead Log (or WAL)

Write Ahead Log is one of those data structures that is equally popular between SQL and NoSQL databases. At its core, it is a simple append-only log of changes that are made to a database.

WAL ensures data durability and can be used to restore state during any catastrophic events. It is also used to buffer writes to database since actual writes to database are often performed in batches at some time later.

Databases like Postgres, RocksDB, and MySQL, all use a WAL under the hood.

Suffix Trees

Suffix tree is yet another advanced structure that is used for full-text search capabilities. It is used to search for the occurrence of a pattern in a large corpus of text efficiently.

Database engines like Elasticsearch and SQLite FTS that supports full-text searching capabilities makes heavy use of such trees.

In the next section, we explore different approaches to code organization. From monorepos to submodules, each method has its advantages and challenges. Choosing the right approach for a given use case isn’t always straightforward, and requires careful consideration.

Finally, in this week’s Tech Spotlight, we take a look at how Jira's engineering team leveraged Protobuf to achieve a 20% faster response time and reduce storage usage by 80%!

🛠️ 10 Techniques for Database Replication

Replicated databases are the reality of modern softwares. Here are 10 techniques that will help you understand the design behind any replicated database ~

• Single Leader Replication - One primary database (leader) handles all writes, and changes are replicated to follower databases.

• Multi Leader Replication - Multiple leader databases allow writes on any node, with changes synchronized across all leaders.

• Leaderless Replication - There is no central leader; all nodes are equal, and updates can happen on any node, with conflict resolution and quorum mechanisms in place.

• Database Snapshot - A point-in-time copy of a database that captures its exact state at the moment of the snapshot.

• Synchronous Replication - Data is written to both the primary and replica databases simultaneously, ensuring strong consistency at the time of the write.

• Asynchronous Replication - Data is written to the primary database first, and then replicated to secondary nodes later, which can result in temporary inconsistency.

• Semi-Synchronous Replication - A hybrid approach where the primary waits for acknowledgment from at least one replica before confirming a write, balancing speed and consistency.

• Chain Replication - Data is replicated in a chain of nodes, where each node forwards updates to the next node in the chain, ensuring consistency across replicas.

• Row-Based Replication - Changes are replicated at the individual row level, capturing only the specific data modified during transactions.

• Statement-Based Replication - Replication occurs by capturing and replaying the SQL statements that caused changes, rather than the actual data modifications.

≫ Subscribe to my Medium blog for an upcoming deep dive

🗂️ Techniques to Organize Codebases

There are several ways in which a library can be shared across different projects.

• Copy’n’Paste: A simple approach where code is duplicated across projects, offering flexibility at the cost of maintainability.

• Multirepo: Each library is kept in its own repository, allowing for clear boundaries but requiring more complex dependency management.

• Git Submodules: A method to include one repository inside another, enabling version control of dependencies but introducing extra complexity with updates and merges.

• Monorepo: All projects and libraries are housed in a single repository, simplifying dependency management and integration but potentially increasing build times and complexity at scale.

🔦 Tech Spotlight!

This week in Tech Spotlight, we’re featuring an insightful blog from Jira's engineering team that explores the practical advantages of using Protobuf over JSON in Jira.

➥ Using Protobuf to make Jira cloud faster

Protobuf is a data serialization/deserialization protocol commonly used with gRPC, but due to technical challenges at Jira, they couldn’t implement gRPC and instead integrated Protobuf directly over REST.

The results were impressive, delivering significant benefits for Jira Cloud, including:

• 75% less CPU usage on the database

• 80% smaller payloads compared to serialized JSON

• 33x faster deserialization and 4x faster serialization

• 20% faster server response times

It’s a must-read for anyone interested in performance optimisation!

And that is it for this week! If you enjoyed what you read, consider clicking the ❤️ button below and leaving a comment.

See you next week in yet another release of System Design Weekly! Till then, happy learning!

During the course of my corporate journey, I have interviewed many candidates for various software engineering roles. Among the many topics I cover, time complexity, asymptotic analysis, and worst-case analysis are the ones where candidates often struggle the most.

The real kicker is that most of these candidates are often highly proficient in advances topics like Algorithm & Data Structure Design, Database Systems, and Computer Network Algorithm. But it is often the strong basics of a candidate that make or break the case for them.

But why so many candidates struggle to analyse the complexity of a piece of code? In my opinion, it is because they over-complicate the process.

Candidates usually tries to perform pattern matching rather than an actual complexity analysis. They tend to evaluate the code based on familiar algorithms and their complexities. However, these candidates struggle significantly when the code doesn’t fit into a known pattern and requires a fresh analysis.

In this blog, I will talk about the methodology I would follow when answering such questions in an interview. As an added bonus, we will specifically talk about answering complexity questions around recursive algorithms.

Subscribe now

Breaking Down The Complex Code Into Independent Pieces

A large piece of code may look daunting at first, so I start by breaking the code into smaller independent pieces.

Every statement, expression, and block of code is an independent component that can be analyzed separately. Therefore, the first step is to examine the method or the script or the code block and identify these distinct components.

Each independent part identified becomes a subtask. These subtasks should then be “recursively” solved for time complexity.

When solution to all these sub-parts have been identified, they can be combined together to form the answer for the larger code.

Specifically, if we are computing the Big-O complexity, the Big-O complexity of the entire code is the largest Big-O complexity of all the sub-parts.

Solving For Loops and Dependent Nested Loops

Breaking the code into independent pieces and solving them individually works well until we hit loops and nested loops. This is where things start becoming interesting.

If the number of times the outermost loop runs, in worst case, is fixed and is not influenced by the code contained in loop’s body then the calculation is simple. I recursively find out the time complexity of the loop’s body and multiply it with the number of times the loop execute!

But life is not always this simple. Consider the following sample code and try to compute its time complexity.

I recommend you to analyse the code and come up with an answer before moving on.

The correct answer is O(N). Well done if you calculated that correctly!

The key is to analyse the code and not jump to a quick & incorrect conclusion that ‘the outer loop will run for N iterations’. In fact, the outer loop will only have two iterations.

A wide range of possibilities can arise when loop variables are updated inside nested loops. While there is no general formula for solutions to such problems, I generally start by following outer loop for 2–3 iterations specifically focusing on nested loops that update the outer loop’s variable. In this way, I grasp how many iterations of outer loop will take place.

Let us take another example.

Let us try to run a few iterations for the outer-loop. We begin with i=n. During the first iteration, the inner loop will run for n iterations until ibecomes 2n. Since the condition for the outer loop is i < n*n, we will continue with the second iteration. In the second iteration, the inner loop will again run n times until i becomes 3n.

Did you start seeing the pattern?

The outer loop is run only when i is n, 2n, 3n, …, (n-1)*n. Thus the outer loop will run only n times.

It is also clear that the inner loop will run n times in each iteration of the outer loop. Thus, assuming the complexity of code contained inside the inner loop to be O(1), the overall complexity can be stated as O(n)*O(n) = O(n^2).

Solving for the Time Complexity of Expressions and Statements

If an expression or statement is composed only up of atomic operations, it is a constant time operation.

// Some constant time operations
int p = q + r;
double c_square = a * a + b * b;
cin >> x;
res |= (1<<j);
p--;

When an expression or statement contains method calls, it is important to analyse those methods before concluding the complexity of the complete expression/statement.

Consider the following example.

Pause for a moment and try to find the time complexity for the expression above!

Since the expression contains function calls, I will begin by first finding out the complexity of the function f1. This function consists of three independent parts of which the first and the third one are constant time operations. For the second part, I observe that the body of the loop is of constant time complexity and the loop runs for x iterations. Thus the overall complexity of the function turns out to be O(x).

When performing an asymptotic analysis of a function call, the complexities of computing the outermost function and its arguments add up.

Based on the observation above, let us first calculate the complexity of the inner most function call i.e., f1(n). As noted earlier, the Big-O complexity for this method call will be O(n) and its return value will be of the order of O(n*n).

Next we will calculate the time complexity for the outermost function call. Since the input to the outermost function is of the order of O(n*n) and the function has the complexity of O(x) where x is the size of input, it is clear that the overall complexity of the outermost function call is O(n*n).

And since for our given statement there are no other operations that takes more than constant time, the overall complexity of the statement is O(n^2).

💡 Most often an expression contains calls to library defined methods that are not directly available for complexity analysis. While it is not possible to memorise the complexity of each and every available method, we should be aware of the data structures and algorithm behind popular interfaces. This will help us estimate the complexity of those methods during interviews.

Complexity Analysis When Dealing With Conditionals

The idea of analysing conditionals is same as that of any other piece of code. You analyse different branches of the conditionals independently and later on combine the results together.

So if I am calculating for the worst time complexity, I would focus on the slowest branch. On the other hand, if I am calculating for the best time complexity, I would consider the fastest of all the branches.

BONUS: Analysing Recursive Code for Complexity

One of the most difficult programs to analyse for time complexities are the recursive programs. This is because many a time the actual complexity of a recursive function is wildly different from a single iteration for that function.

The formal way of calculating the complexities for recursive functions is to use the Master Theorem which is stated as follows.

T(n) = aT(n/b) + f(n),
where,
  n = size of input
  a = number of subproblems in the recursion
  n/b = size of each subproblem. All subproblems are assumed to have the
        same size.
  f(n) = cost of the work done outside the recursive call, which includes
         the cost of dividing the problem and cost of merging the solutions

T(n) has the following asymptotic bounds:

    1. If f(n) = O(nlogb a-ϵ), then T(n) = Θ(nlogb a).

    2. If f(n) = Θ(nlogb a), then T(n) = Θ(nlogb a * log n).

    3. If f(n) = Ω(nlogb a+ϵ), then T(n) = Θ(f(n)).

ϵ > 0 is a constant.

While the Master Theorem is the most recommended method of calculating the complexities of recursive methods, it is often difficult to remember and use specially in an interview setting where you might not have access to the internet to verify the theorem.

When solving for such problem, I generally opt for the tree-diagram method.

In the tree-diagram method, each call to the recursive function is denoted by a tree node. The value on the node denotes the size of the input. Parent-child relationship between the nodes is used to denote the recursive calls made. Here is an example of the tree-diagram for fibonacci recursive code.

Once I have created the tree diagram, I ask myself these three questions ~

• What is the height of the tree when the root has the label of n?

• What is the relation between number of nodes and the tree level?

• What is the largest label of a node at any level?

Once I find the answer to these questions, the problem of finding the worst case time complexity reduces to a simple arithmetic problem.

f(n) = cost of the work done outside the recursive call, which includes
         the cost of dividing the problem and cost of merging the solutions

complexity = O(1)

for tree_level in 0 to max_height(n):
  count = nodes_at_level(tree_level)
  size = largest_node_value_at_level(tree_level)
  complexity += count * f(size)

I have denoted the calculation in pseudo-code but trust me, the calculation on paper is really straightforward.

A solid understanding of computer science fundamentals is a hallmark of a strong candidate. Great developers not only have this knowledge but also possess the ability to analyze their code effectively. Without thorough analysis, even the best code cannot reach its full potential for improvement.

If you reached this far, Congratulations! If you enjoyed reading this article consider liking and leaving a comment. This would greatly help me as a creator!