DEV Community: Le Xuan Kha (Leo)

Golang Design Patterns - Proxy

Le Xuan Kha (Leo) — Tue, 04 Feb 2025 04:29:43 +0000

I. Proxy - Structural Pattern

The Proxy is a familiar Design Pattern for developers, used to represent an original resource. The Proxy provides functionalities similar to the original resource but with high customizability.

The Proxy acts as a substitute for the original resource, hiding complex details or adding necessary features such as access control, caching, or load balancing.

II. Real-world Example

The system frequently needs to query user information from a main database. However, directly querying the main database can increase latency and reduce system performance. Therefore, we use a Proxy that acts as a cache to temporarily store frequently queried data.

The Proxy checks the cache, and if the data exists in the cache, it returns it immediately. Otherwise, it queries the main database and updates the cache.

This use case introduces the mechanism of a Proxy for searching users (User) between the MainDB (main database) and the Stack (cache) to improve performance.

Definition of User:
A User only has an ID attribute (int), representing a user entity.
Shared Interface:
The UserFinder interface defines the Find(ID int) method to search for a user by their ID. Both MainDB and Stack adhere to this interface.
Main Database (MainDB):
The main database where users are stored. UsersDB provides the Find function to search for a user and the Add function to add a new user.
Proxy (UserFinderProxy):
The Proxy is a middle layer that uses the Stack (cache memory) for faster access before searching in the MainDB.

When a User is not in the Stack, the Proxy checks the MainDB.
If the user is found, the Proxy saves the User in the Stack to optimize subsequent queries.
The Stack has a capacity-limiting mechanism and auto-updates when full.

The class diagram for the above scenario would be depicted as follows:

III. Implementation

Definition of the Interface User entity:

package proxy

type User struct {
    ID int
}

Definition of the Interface:

package proxy

type UserFinder interface {
    Find(ID int) (User, error)
}

Definition of Database

package proxy

import "fmt"

type UsersDB []User

func (u *UsersDB) Find(ID int) (User, error) {
    for _, user := range *u {
        if user.ID == ID {
            return user, nil
        }
    }
    return User{}, fmt.Errorf("user not found")
}

func (u *UsersDB) Add(user User) *UsersDB {
    fmt.Println("Adding to database: ", user)
    *u = append(*u, user)
    return u
}

Definition of Proxy:

package proxy

import "fmt"

type UsersStack []User

func (u *UsersStack) Find(ID int) (User, error) {
    for _, user := range *u {
        if user.ID == ID {
            return user, nil
        }
    }
    return User{}, fmt.Errorf("user not found")
}

func (u *UsersStack) Add(user User) *UsersStack {
    *u = append(*u, user)
    return u
}

type UserFinderProxy struct {
    MainDB   UsersDB
    Stack    UsersStack
    Capacity int
}

func (u *UserFinderProxy) Find(ID int) (User, error) {
    user, err := u.Stack.Find(ID)
    if err == nil {
        fmt.Println("Found in stack: ", user)
        return user, nil
    }

    user, err = u.MainDB.Find(ID)
    if err != nil {
        return User{}, err
    }

    fmt.Println("Found in mainDB: ", user)
    u.AddToStack(user)
    return user, nil
}

func (u *UserFinderProxy) AddToStack(user User) error {
    fmt.Println("Adding to stack: ", user)
    if len(u.Stack) >= u.Capacity {
        u.Stack = append(u.Stack[1:], user)
    } else {
        u.Stack.Add(user)
    }
    return nil
}

Run the application:

/*
        Example Proxy
    */
    fmt.Println("*** Example Proxy ***")

    mainDB := proxy.UsersDB{}

    user1 := proxy.User{ID: 1}
    user2 := proxy.User{ID: 2}
    user3 := proxy.User{ID: 3}

    mainDB.Add(user1).Add(user2).Add(user3)

    proxy := proxy.UserFinderProxy{
        MainDB:   mainDB,
        Stack:    proxy.UsersStack{},
        Capacity: 2,
    }

    proxy.Find(1)
    proxy.Find(2)
    proxy.Find(3)
    proxy.Find(2)
    proxy.Find(1)

    fmt.Print("*** End of Proxy ***\n\n\n")

With the output:

IV. Explain the example above

This example illustrates how the Proxy pattern works through querying users (User) from the main database (MainDB) while using a stack-based cache (Stack) to optimize repeated search operations. Below is the step-by-step explanation:

1. Initializing the Main Database (MainDB)

mainDB := proxy.UsersDB{}

user1 := proxy.User{ID: 1}
user2 := proxy.User{ID: 2}
user3 := proxy.User{ID: 3}

mainDB.Add(user1).Add(user2).Add(user3)

A main database (MainDB) is initialized, which holds a list of users (UsersDB).
Three users with IDs 1, 2, and 3 are added to the MainDB. Any query will be able to find these users if searched directly in MainDB.

Log results:

Adding to database:  {1}
Adding to database:  {2}
Adding to database:  {3}

2. Initializing the Proxy with MainDB and Stack

proxy := proxy.UserFinderProxy{
    MainDB:   mainDB,
    Stack:    proxy.UsersStack{},
    Capacity: 2,
}

The UserFinderProxy is created with the following components:

MainDB: The primary database that stores all the users.
Stack: A cache layer that is initially empty.
Capacity: The maximum number of users that the Stack can hold (set to 2 here).

3. Searching for Users

First Search: `proxy.Find(1)`

Proxy checks for ID 1 in the Stack but finds nothing (Stack is initially empty).
Proxy switches to searching in the MainDB and finds the user with ID 1.
The proxy adds this user to the Stack for faster future queries.

Log results:

Found in mainDB:  {1}
Adding to stack:  {1}

Second Search: `proxy.Find(2)`

Proxy checks for ID 2 in the Stack but does not find it.
Proxy searches the MainDB, finds the user with ID 2, and adds it to the Stack.
The Stack now contains two users: {1, 2}.

Log results:

Found in mainDB:  {2}
Adding to stack:  {2}

Third Search: `proxy.Find(3)`

Proxy checks for ID 3 in the Stack but does not find it.
Proxy searches the MainDB and finds the user with ID 3.
The Stack, already at full capacity (2), operates on a FIFO (First In, First Out) mechanism:
- It removes the oldest user (User with ID 1).
- Then, it adds the new user (3).
The Stack now contains {2, 3}.

Log results:

Found in mainDB:  {3}
Adding to stack:  {3}

Fourth Search: `proxy.Find(2)`

Proxy checks for ID 2 in the Stack and finds it directly.
No need to query the MainDB—the search is instant.

Log results:

Found in stack:  {2}

Fifth Search: `proxy.Find(1)`

Proxy checks for ID 1 in the Stack but does not find it (it was removed earlier).
Proxy searches the MainDB and finds the user with ID 1.
The Stack, at capacity, removes the oldest user (User with ID 3) and adds the new user (1).
The Stack now contains {2, 1}.

Log results:

Found in mainDB:  {1}
Adding to stack:  {1}

4. End of Example

Final State:

Stack: Contains {2, 1} (the two most recently queried users).
MainDB: Remains unchanged, containing all users {1, 2, 3}.

Final Log:

*** End of Proxy ***

Summary

For each query, the Proxy first checks the Stack to quickly locate the User.
If the User is not found in the Stack, the Proxy searches the MainDB and adds the result to the Stack for optimized future searches.
The Stack has a capacity limit, and when it is exceeded, the oldest User is removed (FIFO – First In, First Out).

Advantages of this approach:

Reduces the number of accesses to the MainDB when Users are queried repeatedly.
Improves system performance by utilizing the cache (Stack) for faster lookups.

V. Conclusion

We do not always need to use the Proxy design pattern to address similar problems. In some cases, direct access to the database might suffice if the problem is not complex or performance optimization is not required. In other situations, you might consider using the Decorator pattern or other optimization techniques.

The most important thing is to choose the solution that best fits your specific problem.

Thank you for taking the time to read this article! 😊

VI. References

Go Design Patterns (Mario Castro Contreras)
Full source code for Go design patterns: available here.

Building a personal blog with Next.js and Notion

Le Xuan Kha (Leo) — Fri, 21 Jun 2024 07:18:11 +0000

In this article, we will together build the fastest blog for yourself with Next.js and Notion.

I. Prerequisites

Notion is certainly no stranger to everyone. It is an AI-powered workspace that helps users easily plan, take notes, and integrate with many other applications, making it very convenient.

In terms of the idea, we will use Notion as a CMS to manage post information, and Next.js to display that information for users while leveraging SSR to improve SEO and security.

Knowledge of Next.js
Personal Notion account

II. Create a database and access token in Notion

Select a page in Notion to store the database.
Add a new element and choose Database - Full page:
Create the following fields for the database, specifying their type and purpose as follows (these fields are for demo purposes, you can modify them later):
- Title: Already created as Name, change it to Title
- Tags (Multi-select): Topic tags
- Description (Text): Brief description of the post
- PresentativeMedia (Files & media): To store the featured image for the post
- Slug (Text): Used as the post's URL
- Status (Status): Post status, including Draft, Published
Next, you can access notion-integration to generate a secret token linked to your personal Notion account, which will be used to create the above database. Remember to select only the Read permission: Read content, as shown in the image below:
After creating the notion-integration, the next step is to allow this integration to access the database. In the Connect to section, choose the integration you just created (I just created for-show-sample), as shown in the image below:

III. Create sample records in database

Based on the created database structure, we will create some sample records as follows. Note that the status of the posts should be changed to Published.

IV. Using notion-nextjs-mini-kit

You can follow the instructions to clone and run the NextJs source code on your machine here.
As per the installation instructions, you will need to replace 2 environment variables.
NOTION_TOKEN= NOTION_DATABASE_ID=
With:
- The Notion token is the token generated from Step II.
- To get the database ID from the database we created, simply open the database page in the browser and copy the string as shown in the image.
Run the NextJs application above and you will see the results as follows

V. Create content for the page

Create content for the pages based on the data created in the previous database.
Publish the posts (select share -> publish)
Return to our website, click on one of the previous posts to see the results 🎉

VI. Conclusion

References

notion-nextjs-mini-kit: https://github.com/khaaleoo/notion-nextjs-mini-kit

On this guide, I have shown you how to quickly create a personal blog using NextJs and Notion as a database. If you have any questions or contributions, please leave a comment below. Thank you everyone.

Happy coding! 🙌🏻

Security Risk - Timing Attack - Challenging but Entirely Feasible

Le Xuan Kha (Leo) — Fri, 21 Jul 2023 08:31:33 +0000

Timing Attack is one of the techniques that hackers exploit by leveraging server-side computations to adjust attack payloads accordingly.

In this article, I will present the most common example of this type of attack and discuss prevention methods using Golang.

I. Timing Attack

Timing Attack is a type of side-channel attack in which hackers exploit information obtained from the real-time execution time of a specific logic within a system to gradually deduce the final result. It can be considered a form of manual brute force, as it employs a similar method to deduce the result, but the difference lies in the fact that the hacker needs to invest more effort in analyzing the existing data to determine the next input.

Hackers always attempt to take advantage of programming oversights in commonly used logical code segments, which are often trivialized. They also target vulnerabilities present in popular open-source libraries commonly used by developers.

II. Real-world Example

For developers, there are cases where it is necessary to authenticate requests from clients or server-to-server communication. There are various ways to implement this, typically using JWT, OAuth2, OpenID Connect, or third-party authentication services like Google, Facebook, AWS Cognito, etc. One of the common and easy-to-implement methods is using an API key.

However, API keys can still be compromised through several attack vectors, one of which is Timing Attack.

III. Preventing Timing Attacks

While it may be tempting to resort to extreme measures like disconnecting from the internet or using an "invulnerable" application to deter hackers, these approaches are impractical. We cannot completely eliminate the risk of a system being attacked, but by understanding the techniques involved, we can make the hacker's path more difficult.

Let's use Golang as an example for the situation mentioned above. When using an API key, there will undoubtedly be a logic section that performs a comparison between the API key sent with the request and the key stored on the server. Typically, developers use the default comparison operator (e.g., "==") for this purpose, which may seem simple. However, in reality, this can be exploited by hackers.

var (
    a      []byte
    length int = 1e8
    bound  int = length / 10
)

func init() {
    a = make([]byte, length)
    rand.Read(a)
}

func copyStr(changedIndex int) []byte {
    b := make([]byte, length)
    copy(b, a)

    if b[changedIndex] == 0 {
        b[changedIndex] = 1
    } else {
        b[changedIndex] = 0
    }

    return b
}

func formatString(s int) string {
    str := strconv.Itoa(s)
    var result string
    for i := len(str) - 1; i >= 0; i-- {
        if (len(str)-1-i)%3 == 0 && i != len(str)-1 {
            result = "." + result
        }
        result = string(str[i]) + result
    }
    return result
}

func execute(fn func(a, b []byte) bool) {
    for i := length - 1; i > 0; i -= bound {
        b := copyStr(i)

        startTime := time.Now()
        fn(a, b)
        endTime := time.Since(startTime)

        fmt.Printf("Differences at Index: %s, time execute: %s\n", formatString(i), endTime.String())
    }
}

func Compare(a, b []byte) bool {
    return string(a) == string(b)
}

func CompareConstantTime(a, b []byte) bool {
    return subtle.ConstantTimeCompare(a, b) == 1
}

The code above compares two strings of equal length, but if there is a difference at any index, the == operator stops the comparison and returns the result immediately. This timing discrepancy can be exploited by hackers to deduce the correct API key by observing the different execution times for incorrect and partially correct matches.

We used subtle.ConstantTimeCompare function in the above code to ensure a constant-time comparison. It returns 1 if the two strings are equal, 0 if they are different, and immediately returns 0 if the lengths of the strings are not the same. By using this method, we eliminate timing discrepancies, making it harder for attackers to deduce information based on the time taken for the comparison.

func main() {
    fmt.Printf("Length of chars: %s\n\n", formatString(length))

    fmt.Println("Normal comparison: using equal operator")
    execute(Compare)

    fmt.Println("\n" + strings.Repeat("*", 50) + "\n")

    fmt.Println("Constant time comparison: using subtle.ConstantTimeCompare")
    execute(CompareConstantTime)
}

And the result:

In regular string comparison, the execution time increases as the differences between the strings move towards the end. However, with ConstantTimeCompare, the execution time remains nearly the same, regardless of where the differences occur in the strings.

IV. Conclusion

In reality, the execution time can be influenced by various factors like network latency, different threads, and more. Achieving precise results may require conducting multiple trials to minimize any discrepancies. While Timing Attacks are challenging to execute successfully due to these complexities, they are still possible.

Using ConstantTimeCompare does come with a time cost, so it's best to employ it only when truly necessary. In cases where security and protection against Timing Attacks are critical, it's worth the investment.

Thank you all for reading this article.

Rate Limiter in System Design. Part 2 - Commonly Used Algorithms

Le Xuan Kha (Leo) — Wed, 28 Jun 2023 18:10:54 +0000

In Part 1, I provided a general introduction at the conceptual level. In this Part 2, I will discuss the most commonly used algorithms when building a Rate Limiter system. Each algorithm has its own advantages and disadvantages, so let's explore them together.

Leaky Bucket

Conceptually, the Leaky Bucket algorithm operates as follows. The server utilizes a fixed-sized bucket and the bottom of the bucket has a hole (output) to hold a certain number of tokens. In this context, a token represents a request sent to the server.

Tokens are sent to the server by the user (client), and the server acts as the agent that allows tokens to enter or exit the bucket.

To facilitate visualization, you can refer to the accompanying illustration below:

The Leaky Bucket algorithm is not overly complex to implement and maintain on a server or load balancer. Memory management is also relatively straightforward as everything can be configured from the beginning. Due to its high accuracy and efficient resource utilization, many large-scale systems utilize the Leaky Bucket algorithm as a Rate Limiter, with NGINX being a notable example.

Despite its many advantages, the Leaky Bucket algorithm also has some drawbacks:

Burstiness: One drawback of the Leaky Bucket algorithm is that it does not handle sudden or bursty loads of requests well. When a large number of requests arrive at the same time, the algorithm has to process all of them within the same time frame. This can lead to overload and decreased system performance.

Delayed response: The Leaky Bucket algorithm can result in delayed response for access requests that occur after a prolonged "idle" interval, where no requests are being processed. In such cases, the "leak" of requests from the bucket only occurs when the next interval begins, resulting in a longer waiting time for the requests to be processed.

Lack of flexibility in handling prioritized or urgent requests.

Implementation errors: If there is a mistake in implementing the algorithm and the bucket is not handled correctly, some requests may be accepted and processed even though the request rate has exceeded the set limit. This can allow a large number of requests to flood the system, causing overload and potentially making the server unstable or slow.

It's important to consider these limitations and evaluate whether the Leaky Bucket algorithm is suitable for specific use cases or if alternative rate limiting algorithms should be employed.

Fixed Window Counter

The Fixed Window Counter algorithm (abbreviated as FWC) differs from the Leaky Bucket algorithm as it is based on time rather than using a dynamically allocated capacity to control requests. FWC divides time into equal intervals, and each interval has its own counter. When a request arrives, based on the timestamp, the request is allocated to the predefined interval, and the corresponding counter operates (e.g., increments by 1).

When the counter reaches a certain threshold, the request is denied execution and either needs to wait or retry in the next time interval.

With the Fixed Window Counter algorithm, we have the following complexities:

Space Complexity: O(1) for storing the counter for each window.
Time Complexity: O(1) for performing operations like Get and incrementing the counter, as they are simple operations.

The Fixed Window Counter algorithm offers several advantages:

Easy implementation: The algorithm is relatively simple to implement, as it involves dividing time into fixed intervals and maintaining counters for each interval.
Lower memory usage: The algorithm requires minimal memory usage, as it only needs to store the counters for each window.
Compatibility with built-in concurrency technologies: The Fixed Window Counter algorithm can leverage built-in concurrency technologies such as Redis, which provides efficient support for distributed and concurrent operations.

However, there are still several drawbacks to the Fixed Window Counter algorithm:

Lack of flexibility: Due to its reliance on pre-defined configurations, the algorithm lacks the ability to scale up dynamically when needed. Developers have to manually adjust the configurations for each campaign or when there is a sudden increase in request volume.
Inherited issues from previous windows: The algorithm does not effectively address situations where a previous window exceeds the request limit. Subsequent windows may not be able to compensate for the excess requests, as the algorithm lacks the ability to dynamically adjust the capacity.
Inability to prioritize or handle urgent requests: The Fixed Window Counter algorithm treats all requests within a window equally and does not differentiate or prioritize urgent requests. This limitation may not be suitable for scenarios where certain requests require immediate processing.

Sliding Window Log & Sliding Window Counter

In the two aforementioned algorithms, although they are easy to implement, each has its own limitations. Sliding Window Log & Counter (SWLC) algorithm is used to mitigate some of these challenges.

The Sliding Window Log & Counter algorithm (SWLC) stores and operates based on the executing agent. When a request is sent to the server, the system identifies the request based on specific criteria such as tokens, IP addresses, etc.

SWLC commonly utilizes an SLA (Service Level Agreement) table, where it logs all user actions. It is a simple key-value structure, with the key consisting of the (token, IP) combination and the value representing the requested data sent by the user.

The Sliding Window Log & Counter algorithm described in the diagram above sets a maximum limit of 2 requests per user within each window. The counter will track and reject any third request from the same user within the same time window.

At its basic level, the Sliding Window Log & Counter algorithm has the following complexities:

Space Complexity: O(number of requests read by the server in one window). The server needs to perform this task to identify the user/IP associated with each request.
Time Complexity (Sliding Window Log): O(number of requests read by the server in one window)
Time Complexity (Sliding Window Counter): O(1). This is a key difference between Sliding Window Counter (SWC) and Sliding Window Log (SWL). SWC only stores the current window (without the need to look back at previous windows).

The advantages of this algorithm include addressing the drawbacks of the two algorithms mentioned earlier and combining the three elements of quantity, agent, and time mentioned in Part 1. So, what are the disadvantages of this algorithm?

Difficult to implement: Combining all three factors certainly adds complexity to the implementation.
Resource consumption: It requires significant memory usage for storing all users within a window.
Complexity increases with the number of requests.

Summary

Here are some commonly used algorithms for building a Rate Limiter system. If there are any other algorithms or better ones, please let me and everyone else know!

Thank you all

See more

Part 1: Rate Limiter in System Design. Part 1 - Concepts and Applications

Rate Limiter in System Design - Part 1: Concepts and Applications

Le Xuan Kha (Leo) — Mon, 26 Jun 2023 09:09:35 +0000

What is Rate Limiter

In the simplest terms, a Rate Limiter restricts the number of access requests to a resource on a system from an agent (such as a user, browser, or another server) within a specific time frame.

Based on several rate limiting techniques, when a violation or a defined threshold is reached, those requests will be blocked from accessing the system.

The three key elements emphasized here are: quantity, agent, and time, which are also the core concepts of a Rate Limiter. These elements will be the focus of today's article.

Rate Limiters in Practical Examples

Surely, you may have encountered or witnessed one of the following situations:

"The PIN for the card has been entered incorrectly more than 5 times. Please contact the bank to unlock the card."
In some applications, when you enter the wrong password multiple times, you receive a notification similar to: "The number of requests exceeds the allowed limit".
Typically, IP addresses from somewhere are easily blocked by foreign e-commerce websites due to previous attacks.
When you request an OTP (One-Time Password) too many times within a minute, you have to wait until the designated time has passed before requesting a new OTP message.

These are examples of practical situations where rate limiters or similar mechanisms are implemented to control and manage access, ensure security, and prevent abuse or unauthorized usage.

If you pay close attention, you will notice that examples 1 and 2 are related to the quantity factor, example 3 addresses the agent factor, and finally, we have the time factor. These are indeed the core elements of a Rate Limiter, and a proper Rate Limiter typically combines all three of these factors together.

Why do we need Rate Limiters?

While the necessity of Rate Limiters depends on the specific system, in small to medium-scale environments, it may not be as critical for certain tasks. However, as systems grow larger in scale, it becomes increasingly important to consider and prioritize Rate Limiters. Here are some reasons why:

Security: One of the primary reasons to implement Rate Limiters is to enhance security. They help mitigate various types of attacks, including Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) attacks. Rate Limiters can also protect against brute force attacks, credential stuffing attacks, web scraping, and other malicious activities.

Resource Balancing: Rate Limiters ensure that server resources are not overloaded and that resources are allocated fairly and reasonably to each user on the system. By controlling the rate of access, Rate Limiters help prevent resource exhaustion and ensure a smooth and efficient operation of the system.

Cost Savings: Having controlled access to resources can contribute to minimizing the overall system costs. By preventing excessive usage and optimizing resource allocation, Rate Limiters can help reduce infrastructure expenses and mitigate the need for additional resources due to uncontrolled growth.

In summary, Rate Limiters are crucial for larger-scale systems as they play a significant role in maintaining security, balancing resource utilization, and optimizing costs.

Some commonly used algorithms in Rate Limiters include:

Leaky Bucket: The Leaky Bucket algorithm regulates the rate of requests by imagining a bucket that can hold a certain number of tokens. Tokens are added to the bucket at a fixed rate, and each request consumes a token. If the bucket is full and a request arrives, it is considered to be overflowing and can be limited or discarded.

Fixed Window Counter: This algorithm counts the number of requests within a fixed time window. If the count exceeds a predefined threshold, subsequent requests can be limited or blocked until the next window starts.

Sliding Window Log: The Sliding Window Log algorithm maintains a log of request timestamps within a sliding time window. It calculates the number of requests within the window and compares it against a defined limit. If the limit is exceeded, requests can be limited or rejected.

Sliding Window Counter: Similar to the Fixed Window Counter, this algorithm counts the number of requests within a sliding time window. However, it allows more flexibility by continuously sliding the window instead of using fixed time intervals.

In Part 2 of the article, I will provide detailed explanations of these algorithms. Stay tuned!

Thank you all for reading the article.

DEV Community: Le Xuan Kha (Leo)

Golang Design Patterns - Proxy

I. Proxy - Structural Pattern

II. Real-world Example

III. Implementation

IV. Explain the example above

1. Initializing the Main Database (MainDB)

2. Initializing the Proxy with MainDB and Stack

3. Searching for Users

First Search: proxy.Find(1)

Second Search: proxy.Find(2)

Third Search: proxy.Find(3)

Fourth Search: proxy.Find(2)

Fifth Search: proxy.Find(1)

4. End of Example

Final State:

Summary

V. Conclusion

VI. References

Building a personal blog with Next.js and Notion

I. Prerequisites

II. Create a database and access token in Notion

III. Create sample records in database

IV. Using notion-nextjs-mini-kit

V. Create content for the page

VI. Conclusion

References

Security Risk - Timing Attack - Challenging but Entirely Feasible

I. Timing Attack

II. Real-world Example

III. Preventing Timing Attacks

IV. Conclusion

Rate Limiter in System Design. Part 2 - Commonly Used Algorithms

Leaky Bucket

Fixed Window Counter

Sliding Window Log & Sliding Window Counter

Summary

See more

Rate Limiter in System Design - Part 1: Concepts and Applications

What is Rate Limiter

Rate Limiters in Practical Examples

Why do we need Rate Limiters?

Some commonly used algorithms in Rate Limiters include:

First Search: `proxy.Find(1)`

Second Search: `proxy.Find(2)`

Third Search: `proxy.Find(3)`

Fourth Search: `proxy.Find(2)`

Fifth Search: `proxy.Find(1)`