This is a guest post by Dr. Ashish Bamania. He’s an AI engineer and author of multiple newsletters including Into AI and Into Quantum.

All popular AI systems that you see today are made up of basic computing units called Neurons or Perceptrons. These connect to form a network called a Neural network that performs various complex computations.

In this lesson, we will understand how neural networks work and how they solve challenging problems, such as generating text, recognizing objects, controlling a robot, and more.

Let’s begin!

To Begin, What is a Neuron?

A Neuron (also called a Perceptron) is inspired by a nerve cell (also called a Neuron) in the body.

It accepts single or multiple inputs, performs calculations on them, and generates an output.

It is implemented using a simple linear equation as shown below.

The job of a neuron is to find or approximate a function that somehow connects the output to its inputs. This function can be as simple or complex as possible.

Now that’s tough, especially when a neuron is just a linear function. Since most real-world functions cannot be approximated with a linear function, a neuron uses an Activation function to capture the non-linearities in its input.

Some of the commonly used Activation functions in neural networks are as follows:

• Sigmoid: An S-shaped function that squashes an input into a value between 0 and 1.

• TanH: An S-shaped function that squashes an input into a value between -1 and 1.

• ReLU or Rectified linear unit: A function that outputs the input directly if it is positive, but converts all negative inputs into 0.

How does a Neuron learn?

A neuron uses parameters called Weights and Biases to learn the relationship between its inputs and outputs. These parameters are not fixed and change as a neuron learns.

A neuron on its own isn’t a very powerful learner, and this is why multiple neurons are stacked together to form a Neural network. Since neurons are also called Perceptrons and these networks consist of multiple layers of them, this architecture is also called a Multi-layer Perceptron (MLP).

Stacking neurons into a network

Check out an example below where we have stacked 5 neurons together in 3 layers.

Since the output of each neuron is transmitted to every other neuron in the next layer, these are called Dense layers. (The other category being Sparse layers, which we won’t discuss in this article.)

The layers of the neural network are categorized as follows:

1. Input layer (with neurons 1 and 2): Takes an input

2. Hidden layer (with neurons 3 and 4): Performs most calculations

3. Output layer (with neuron 5): Outputs the result

Zooming in, each neuron in these layers receives input, which is multiplied by a unique weight and bias terms specific to that neuron, and generates an output that is passed to another neuron.

These calculations continue till a final output from the neural network is generated. This process of calculating the output of a neural network from its inputs is called the Forward Pass, or Forward Propagation.

Since data flows from the Input layer to the Output layer, which is an imagined forward direction, this network is called a Feed-Forward Network. (The other category being Recurrent neural networks, which we won’t be discussing in this article.)

How does a neural network learn?

A neural network learns by iteratively updating its parameters until it approximates the function that maps its inputs to outputs.

At the beginning of training, when a neural network generates an output given its inputs, the output is mostly gibberish because the parameters in each neuron are randomly set.

For learning, the generated output is compared with the true value (the output that we intend the neural network to generate) using a Loss function.

This loss function is a mathematical formula that measures the error between the network’s generated/predicted output and the true value.

Some commonly used loss functions are:

• Mean Absolute Error: The average of the absolute differences between the network’s output values and the true values (used for regression problems)

• Mean Squared Error: The average squared difference between the network’s output values and the true values (used for regression problems)

• Binary/ Categorical Cross-Entropy: Measure of the performance of a classification model whose output is a probability value between 0 and 1.

This measure of error or Loss is used to update the parameters (weights and biases) in a process called the Backward Pass or Backpropagation.

Each parameter is updated in proportion to its contribution to the overall loss. This ensures that, in the next forward pass, the loss is smaller than in this one, and the model learns by reducing the loss.

The algorithm used for this parameter update process is called an Optimization algorithm, or Optimizer. Some commonly used optimizers are as follows:

• Gradient Descent

• Adam

• Muon

To ensure that parameter values do not change a lot in a single step of optimization, updates are scaled using a value called the Learning rate.

These training runs, each consisting of a forward and a backward pass, continue for multiple turns.

The loss value decreases in each run until the network starts outputting a value that is very close to the true value. This finishes the neural network training.

An example of a neural network learning to identify images

Let’s take an example of a neural network learning to identify whether a given image is of a cat or a dog.

The training starts with a huge dataset of mixed images of dogs and cats. At each step, the network is given an image as input and asked to output what it thinks the image is (Forward pass).

In the following example, the untrained neural network outputs “Cat” for the dog’s image. We need to fix this.

The output (“Cat”) and the true value (“Dog”) are compared using a Loss function, which outputs an error called Loss.

This loss value is then used to update the parameters during the backward pass. The parameter update is in a direction that leads to lower loss in the next training run.

This process continues until the neural network generates the correct output (“Dog”) for the image.

I’ve only shown this for dog images, but a similar process applies to cat images as well. The training ends when the neural network starts identifying the correct label for the images.

Authentication. Rate limiting. Request logging. The same logic gets duplicated across services, with slight variations and inevitable bugs.

An API Gateway fixes this by introducing a single entry point for all client requests.

Instead of spreading these cross-cutting concerns across your services, you move them to one place. The gateway handles routing, security, traffic control, and more, so your services can stay focused on business logic.

In this article, we’ll break down the top 10 API Gateway use cases, how they work, and why they should belong at the gateway layer.

1. Request Routing

At its core, an API Gateway is a traffic controller. Its primary job is simple: take an incoming request and send it to the right service.

In a microservices architecture, each service owns a specific domain such as users, orders, payments, or inventory. But clients don’t need to know where these services live or how many instances are running. They just send requests to the gateway, and the gateway takes care of the rest.

Routing decisions are usually based on things like the URL path, HTTP method, headers, or query parameters. For example, requests to /api/users go to the User Service, while /api/orders is handled by the Order Service.

Here’s what a routing configuration looks like in practice:

# API Gateway routing rules
routes:
  - path: /api/users/**
    service: user-service
    methods: [GET, POST, PUT, DELETE]

  - path: /api/orders/**
    service: order-service
    methods: [GET, POST]

  - path: /api/payments/**
    service: payment-service
    methods: [POST]

  - path: /api/inventory/**
    service: inventory-service
    methods: [GET]

Behind the scenes, the gateway often integrates with service discovery systems like Consul or Kubernetes DNS. So when a new instance of a service spins up, the gateway can find it automatically without any manual updates.

This decouples clients from your backend. Services can scale, move, or even be renamed without breaking anything on the client side.

But routing alone isn’t enough. Once a request reaches your system, you still need to decide whether the client should be allowed to make that request in the first place.

2. Authentication and Authorization

Every API request needs to answer two questions: Who is this? And are they allowed to do this?

Without an API Gateway, each microservice has to implement its own authentication and authorization logic. That quickly leads to duplicated code, inconsistent checks, and subtle security gaps.

An API Gateway fixes this by making security a first-class, centralized concern. It intercepts every request, validates the credentials, and only forwards requests that pass the checks. By the time a request reaches a backend service, it’s already trusted.

The most common approach is validating a JWT (JSON Web Token). The client sends the token in the Authorization header, and the gateway verifies its signature, expiration, and permissions before routing the request.

A typical token validation flow at the gateway looks like this:

def authenticate_request(request):
    token = request.headers.get("Authorization", "").replace("Bearer ", "")

    if not token:
        return {"status": 401, "error": "Missing token"}

    try:
        # Verify JWT signature and decode claims
        payload = jwt.decode(token, PUBLIC_KEY, algorithms=["RS256"])

        # Check token expiration
        if payload["exp"] < current_time():
            return {"status": 401, "error": "Token expired"}

        # Check if user has required role for this endpoint
        required_role = get_required_role(request.path, request.method)
        if required_role not in payload.get("roles", []):
            return {"status": 403, "error": "Insufficient permissions"}

        # Attach user context for downstream services
        request.headers["X-User-ID"] = payload["sub"]
        request.headers["X-User-Roles"] = ",".join(payload["roles"])
        return {"status": 200, "user": payload}

    except jwt.InvalidTokenError:
        return {"status": 401, "error": "Invalid token"}

Gateways can also support API keys for internal services and OAuth 2.0 flows for third-party integrations. The key idea is simple: enforce security once, at the edge, instead of reimplementing it everywhere.

Once you know who the client is and what they can do, the next challenge is controlling how much they can do without overwhelming your system.

3. Rate Limiting and Throttling

Read more

OpenClaw is one of the craziest AI tools launched this year. It became so popular that people started hoarding Mac minis to run it, and its founder, Peter Steinberger, was hired by OpenAI.

If you haven’t yet heard of it, OpenClaw is a free and open-source autonomous AI agent that can complete tasks for you. It can read your inbox, send emails, manage your calendar, and check you in for flights, all from WhatsApp, Telegram, or any chat app that you already use. (That’s how the official website describes it.)

A large audience believes that OpenClaw could be AGI. This is one of the reasons (besides my genuine curiosity about disassembling its components) why I decided to rebuild a simple version of it and teach you everything from scratch.

Let’s build “Tiny-Openclaw”!

What Are We Building?

Before we begin, we need to know what the real OpenClaw can do.

• It can run on any Mac/ Windows/ Linux machine and use proprietary or local LLMs.

• One can talk to it using any chat app.

• It remembers your conversations and preferences (this means that it has persistent memory).

• It can browse the internet, fill forms, and extract data from websites.

• It has full access to all the files on your computer.

• It can use Skills (either built by you or the community), which are simply bundles of instructions, scripts, and resources that help an AI agent to complete a specific task.

Similarly, our tiny version of OpenClaw, called “Tiny-OpenClaw”:

• Runs on a Mac/ Windows/ Linux machine

• Can browse the internet, fill forms, and gather data from websites

• Uses Skills

• Has persistent memory

• One can use Telegram to communicate with it

Tiny-OpenClaw does not have full system access on a machine, as it poses significant security risks, and this tutorial is not intended for creating an AI bot for production use.

Components That Make Up Tiny-OpenClaw

Before we start coding, let’s understand the 8 components that make up Tiny-OpenClaw.

1. Telegram Channel: This is an adapter specific to the messaging platform that translates messages from the platform’s format to a standard format that OpenClaw can work with.

2. Session Manager: This manages separate sessions and conversation histories per user.

3. Agent runtime: This is a loop that sends prompt and context to an LLM agent, runs tools if needed, and returns a final answer.

4. Memory: This is the storage that helps persist a user’s data across different chat sessions.

5. SOUL.md: This markdown file defines the agent’s personality and operating rules.

6. Skills: These are folders containing instructions, scripts, and resources to help complete a specific task.

7. Skills loader: This looks for the available Skills at startup, reads each Skill’s description and tools, and routes tool calls from the LLM to the right handler.

8. Context builder: This combines the following and returns context for the LLM:

   • SOUL.md

   • Skill descriptions

   • Saved memory about the user

   • Current time

We will build these one by one.

The following diagram shows how these components connect together.

Before we start, I want to introduce you to my book, LLMs In 100 Images, which is a collection of 100 easy-to-follow visuals that explain the most important concepts you need to master to understand LLMs today.

Grab your copy

Let’s move forward!

1. Creating the Project

Start by typing the following bash commands in your terminal to create the scaffold for the project.

# Create project folder
mkdir tiny-openclaw && cd tiny-openclaw

# Create folders for skills and frontend
mkdir -p skills/datetime skills/memory_work skills/browser_use

# Create core component files
touch main.py agent_runtime.py context_builder.py session_manager.py telegram_channel.py memory_store.py skill_loader.py SOUL.md .env

# Create datetime skill files
touch skills/datetime/SKILL.md skills/datetime/handler.py

# Create memory note skill files
touch skills/memory_work/SKILL.md skills/memory_work/handler.py

# Create Browser use skill files
touch skills/browser_use/SKILL.md skills/browser_use/handler.py

Next, create a virtual environment and install all the dependencies using uv as follows.

# Create and activate virtual environment
uv venv
source .venv/bin/activate

# Install dependencies with uv
uv pip install httpx python-dotenv python-telegram-bot playwright

# Download the Chromium browser binary that Playwright needs for the Browser use skill
playwright install chromium

2. Building Memory

Tiny-OpenClaw’s memory is a simple key-value store (dictionary) that persists data as a JSON file on disk. It is used to store user preferences and facts for the LLM agent to retrieve later.

(Feel free to use an in-memory database like Redis if you prefer it over the simple dictionary we are using here.)

# ./memory_store.py

import json
import os

# Key-value store
class Memory:
    def __init__(self, path="MEMORY.json"):
        self.path = path

        # Load existing memory from disk if available
        if os.path.exists(path):
            with open(path) as f:
                self._data = json.load(f)
        else:
            self._data = {} # Dictionary used to store user memories

    # Set a key-value pair
    def set(self, key, value):
        self._data[key] = value
        self._save()

    # Get a value by key
    def get(self, key):
        return self._data.get(key)

    # Get all keys
    def keys(self):
        return list(self._data.keys())

    # Save memory to disk
    def _save(self):
        with open(self.path, "w") as f:
            json.dump(self._data, f, indent=2, default=str)

3. Building the Session Manager

The Session manager’s job is to create and track a separate conversation history for each user. It works like this:

• When a user connects to Tiny-Openclaw, it creates a session using their client ID and channel (which could look like telegram:123) to keep their conversations separate.

• All messages (from the user and the LLM assistant) are added to that session’s history. This history is sent to the LLM as context on every turn, so that it knows what the user has been chatting about.

• Sessions are saved to disk as a JSON file (SESSIONS.json) so that the conversations aren’t lost when the system restarts.

# ./session_manager.py

import json
import os
import time

class SessionManager:
    def __init__(self, path="SESSIONS.json"):
        self.path = path

        # Load sessions from the disk if available
        if os.path.exists(path):
            with open(path) as f:
                self.sessions = json.load(f)
            print(f" Restored previous session(s) from disk!")
        else:
            self.sessions = {}

    # Find an existing session or create a new one 
    def get_or_create_session(self, client_id, channel):
        session_id = f"{channel}:{client_id}" 

        if session_id not in self.sessions:
            self.sessions[session_id] = {
                "client_id": client_id,
                "channel": channel,
                "created_at": time.time(),
                "history": [],
            }

        return session_id

    # Append a message from user or LLM to the session history
    def add_message(self, session_id, message):
        session = self.sessions.get(session_id)
        if session:
            session["history"].append(message)
            self._save()

    # Return the full conversation history for a session to send to LLM as context on every turn 
    def get_history(self, session_id):
        session = self.sessions.get(session_id)
        return session["history"] if session else []

    # Save sessions to disk
    def _save(self):
        with open(self.path, "w") as f:
            json.dump(self.sessions, f, indent=2, default=str)

A sample SESSION.json file is shown below to show what it stores.

{
  "telegram:1191237804": {
    "client_id": "1191237804",
    "channel": "telegram",
    "created_at": 1774270494.7631621,
    "history": [
      {
        "role": "user",
        "content": "Hi!",
        "timestamp": 1774270494.7631638
      },
      {
        "role": "assistant",
        "content": "Hello! I'm your personal AI assistant. What can I help you with today?",
        "timestamp": 1774270497.646961
      },
      {
        "role": "user",
        "content": "Remember my name is ashish",
        "timestamp": 1774270609.259111
      },
      {
        "role": "assistant",
        "content": "Perfect! I've saved your name as Ashish in my memory. I'll remember this for future conversations. Nice to meet you, Ashish!",
        "timestamp": 1774270611.7315981
      }
    ]
  }
}

4. Setting Up Skills

Skills give Tiny-OpenClaw the ability to solve specific tasks. Each Skill is implemented as a folder with two files:

• SKILL.md: A Markdown file that contains the name and short description of the Skill. These are appended to the System prompt so the LLM knows this Skill exists and when to use it.

• handler.py: The code that executes when the LLM decides to use a particular Skill

What’s interesting is that instead of hardcoding the logic, we let Tiny-OpenClaw know which Skills it has access to and let it figure out on its own whether to use them or not during a conversation turn.

We will be building three Skills for this project as follows:

1. Date/Time: Helps find the current date and time

2. Memory work: Helps save personal notes about a user in memory

3. Browser Use: Helps visit websites, extracts text content, clicks elements, and fills forms.

1. Date/Time Skill

Here is the skills/datetime/SKILL.md file for this Skill.

---
name: datetime
description: Get the current date and time.
---

The handler.py for this Skill is as follows.

# ./skills/datetime/handler.py

from datetime import datetime, timezone

# Tool definition to tell the agent about the available 'get_current_datetime' tool
tools = [
    {
        "name": "get_current_datetime",
        "description": "Get the current date and time.",
        "parameters": {
            "type": "object",
            "properties": {},
            "required": [],
        },
    }
]

# Function called when the agent invokes this tool
async def execute(tool_name, tool_input, context):
    if tool_name == "get_current_datetime":
        # Get the current date and time
        now = datetime.now(timezone.utc)

        # Return a human-readable format 
        return {
            "readable": now.strftime("%A, %B %d, %Y %I:%M:%S %p UTC"),
        }

    return {"error": f"Unknown tool: {tool_name}"}

2. Memory work Skill

Here is the skills/memory_work/SKILL.md file for this Skill.

---
name: memory_work
description: Save a note to the user’s personal memory.
---

The handler.py for this Skill is as follows.

# ./skills/memory_work/handler.py

# Tool definition to tell the agent about the available 'save_note' tool
tools = [
    {
        "name": "save_note",
        "description": "Save a note or fact about the user to memory.",
        "parameters": {
            "type": "object",
            "properties": {
                "key": {"type": "string", "description": "Short descriptive key"},
                "content": {"type": "string", "description": "Note content"},
            },
            "required": ["key", "content"],
        },
    },
]

# Function called when the agent invokes this tool
async def execute(tool_name, tool_input, context):
    memory = context["memory"]

    if tool_name == "save_note":
        # Save to memory
        memory.set(f"note:{tool_input['key']}", {
            "content": tool_input["content"],
        })

        return {"success": True, "key": tool_input["key"]}

    return {"error": f"Unknown tool: {tool_name}"}

3. Browser Use Skill

Here is the skills/browser_use/SKILL.md file for this Skill.

---
name: browser_use
description: Browse the web, extract text from webpages, click elements, and fill and submit forms. Use when the user asks to visit a website, read a page, or interact with web content.
---

The handler.py for this Skill uses Playwright, a library for browser automation that gives Tiny-OpenClaw the ability to work with webpages.

# ./skills/browser_use/handler.py

from playwright.async_api import async_playwright

# Global browser state that is initialized on first tool call
_browser = None
_page = None

async def _get_page():
    global _browser, _page

    # If a browser and page are already active, reuse them instead of reopening
    if _browser and _page:
        return _page

    # Start Playwright
    pw = await async_playwright().start()

    # Launch a new Chromium browser instance
    # 'headless=True' means that the browser window will not be visible during execution
    _browser = await pw.chromium.launch(headless=True)

    # Open a new page (tab) in the launched browser
    _page = await _browser.new_page()

    return _page

We add the definitions of all available tools next to this file.

# ./skills/browser_use/handler.py (continued)

# Tool definitions for available tools
tools = [
    {
        "name": "browse_url",
        "description": "Navigate to a URL and return the page title and text content.",
        "parameters": {
            "type": "object",
            "properties": {
                "url": {"type": "string", "description": "The URL to visit"},
            },
            "required": ["url"],
        },
    },
    {
        "name": "click_element",
        "description": "Click an element on the page by CSS selector or text.",
        "parameters": {
            "type": "object",
            "properties": {
                "selector": {
                    "type": "string",
                    "description": "CSS selector or text content, e.g. 'button.submit' or 'text=Sign In'",
                },
            },
            "required": ["selector"],
        },
    },
    {
        "name": "fill_input",
        "description": "Type text into an input field.",
        "parameters": {
            "type": "object",
            "properties": {
                "selector": {"type": "string", "description": "CSS selector for the input"},
                "text": {"type": "string", "description": "Text to type"},
            },
            "required": ["selector", "text"],
        },
    },
    {
        "name": "get_page_content",
        "description": "Get the text content of the current page or a specific element.",
        "parameters": {
            "type": "object",
            "properties": {
                "selector": {
                    "type": "string",
                    "description": "Optional CSS selector to extract text from, e.g. '#title' or '.content' If empty, returns full page text.",
                },
            },
            "required": [],
        },
    },
]

And then we add the functions that are executed when a tool is called.

# ./skills/browser_use/handler.py (continued)

# Function called when the agent invokes a tool
async def execute(tool_name, tool_input, context):
    try:
        # Create a browser page
        page = await _get_page()

        if tool_name == "browse_url":
            url = tool_input["url"] # Extract the URL from the tool input

            # Add "https://" if the URL doesn’t already include it
            if not url.startswith("http"):
                url = "https://" + url 
            
            # Visit URL ('wait_until' ensures the DOM is ready, 'timeout' prevent hanging indefinitely)
            await page.goto(url, wait_until="domcontentloaded", timeout=10000)

            # Get the page title
            title = await page.title()

            # Get the all text from the <body> element
            text = await page.inner_text("body")

            # Return a structured response
            return {
                "title": title,
                "url": page.url,
                "content_preview": text.strip()[:3000],  # Trim to stay within LLM context limits
            }

        elif tool_name == "click_element":
            # Click using a CSS selector ('timeout' prevent hanging if element isn't found)
            await page.click(tool_input["selector"], timeout=3000)
            
            # Wait for page to update after the click
            await page.wait_for_load_state("domcontentloaded")

            # Return a structured response
            return {
                "clicked": tool_input["selector"],
                "new_url": page.url,
                "new_title": await page.title(),
            }

        elif tool_name == "fill_input":
            # Fill the specified input field with given text
            await page.fill(tool_input["selector"], tool_input["text"])
            
            # Return a structured response for confirmation
            return {
                "filled": tool_input["selector"],
                "text": tool_input["text"],
            }

        elif tool_name == "get_page_content":
            # Use the given selector or the page body
            selector = tool_input.get("selector") or "body"

            # Extract text from selected element 
            text = await page.inner_text(selector)

            # Return trimmed content to stay within LLM context limits
            return {
                "url": page.url,
                "content": text.strip()[:5000],
            }
        
        # Handle error for unknown tool
        return {"error": f"Unknown tool: {tool_name}"}

    except Exception as e:
        return {"error": str(e)}

5. Building the Skill Loader

The Skill loader goes through each Skill and:

• Reads its SKILL.md to get its name and description

• Imports its handler.py to get the tool definitions and the execute function

• Later, when Tiny-OpenClaw decides to call a tool, the Skill loader figures out which Skill owns that tool and runs its handler.

#./skill_loader.py

import os
import importlib.util

class SkillLoader:
    def __init__(self):
        self.skills = {}

    # Scan the 'Skills' folder and load each Skill
    def load_from_directory(self, skills_dir):
        if not os.path.isdir(skills_dir):
            print("No Skills directory found.")
            return

        for entry in os.listdir(skills_dir):
            skill_dir = os.path.join(skills_dir, entry)
            skill_md = os.path.join(skill_dir, "SKILL.md")
            handler_py = os.path.join(skill_dir, "handler.py")

            # Skip if folder doesn't have both required files
            if not os.path.isdir(skill_dir):
                continue
            if not os.path.exists(skill_md) or not os.path.exists(handler_py):
                continue

            try:
                # Read name and description from SKILL.md
                with open(skill_md) as f:
                    name, description = self._parse_skill_md(f.read())

                # Import handler.py at runtime
                # Tell Python where the file is
                spec = importlib.util.spec_from_file_location(f"skill_{entry}", handler_py)
                
                # Create an empty module from that spec
                module = importlib.util.module_from_spec(spec)
                
                # Run the file and fill the module with its contents
                spec.loader.exec_module(module)

                # Get the tools list and execute function from the loaded module
                self.skills[name] = {
                    "name": name,
                    "description": description,
                    "tools": getattr(module, "tools", []),
                    "execute": getattr(module, "execute", None),
                }

                print(f"Skill Loaded: {name}")

            except Exception as e:
                print(f"Failed to load {entry}: {e}")

    # Helper function to get Skill names and descriptions for the system prompt
    def get_active_skills(self):
        return [
            {"name": s["name"], "description": s["description"]}
            for s in self.skills.values()
        ]

    # All tool definitions from all skills, sent to the LLM
    def get_tools(self):
        tools = []

        for skill in self.skills.values():
            tools.extend(skill["tools"])

        return tools

    # Find which skill owns this tool and run it
    async def execute_tool(self, tool_name, tool_input, context):
        for skill in self.skills.values():
            if any(t["name"] == tool_name for t in skill["tools"]):
                if skill["execute"]:
                    return await skill["execute"](tool_name, tool_input, context)

        return {"error": f"Unknown tool: {tool_name}"}

    # Extract name and description from SKILL.md frontmatter
    def _parse_skill_md(self, content):
        # Defaults
        name = "unknown"       
        description = ""

        for line in content.split("\n"):
            if line.startswith("name:"):
                name = line.split(":", 1)[1].strip()
            elif line.startswith("description:"):
                description = line.split(":", 1)[1].strip()

        return name, description

6. Giving the Bot a Personality

We use a Markdown file called SOUL.md to give Tiny-OpenClaw its personality characteristics and operating rules.

Note that the original OpenClaw uses various workspace files, such as SOUL.md, AGENTS.md, USER.md and IDENTITY.md for different functions, but we just stick to one.

# Soul
You are Tiny-OpenClaw, a personal AI assistant running on the user's own machine. You have access to tools provided by installed skills.

## Personality
- Friendly, concise and occassionally funny
- Use a casual tone like when texting a smart friend
- When unsure, say so honestly, rather than making facts up

## Rules
- When saving notes, use short consistent keys like "name", "location", "job"
- When searching the web, always use DuckDuckGo instead of Google
- Use available tools wherever necessary
- Never run destructive commands without asking first
- Keep responses under 300 words unless asked for detail

7. Setting Up the Context Builder

The Context builder assembles everything Tiny-OpenClaw needs to know before responding.

It combines the following into a single System prompt sent with every LLM call to provide all the essential context.

• SOUL.md

• Skill names and descriptions

• Saved memory about the user

• Current time

# ./context_builder.py

import os
from datetime import datetime, timezone

BASE_PROMPT = """You are a helpful personal AI assistant powered by Tiny OpenClaw.
Be concise, friendly, and helpful. Use tools when they would help."""

# Load SOUL.md
def load_soul():
    # Path to SOUL.md
    soul_path = os.path.join(os.path.dirname(__file__), "SOUL.md")
    
    # Open the file
    try:
        with open(soul_path, "r") as f:
            return f.read()
    except FileNotFoundError:
        return BASE_PROMPT

# Combine Soul.md, Skills, User memory and Current time into a System prompt
def build_system_prompt(active_skills, memory=None):
    prompt = load_soul() # Load SOUL.md

    # Add name and descriptions of available Skills
    if active_skills:
        prompt += "\n\n## Available Skills\n"
        for skill in active_skills:
            prompt += f"### {skill['name']}\n"
            prompt += f"{skill['description']}\n\n"

    # Add details from saved memory about the user
    if memory:
        prefix = "note:"
        notes = {
            k[len(prefix):]: memory.get(k)
            for k in memory.keys()
            if k.startswith(prefix)
        }

        if notes:
            prompt += "\n\n## What you know about the user\n"
            for key, value in notes.items():
                content = value.get("content", value) if isinstance(value, dict) else value
                prompt += f"- {key}: {content}\n"

    # Add current time
    prompt += f"\nCurrent time: {datetime.now(timezone.utc).isoformat()}"

    return prompt

8. Getting the Agent Runtime Ready

The Agent runtime is the brain of Tiny-OpenClaw. It is based on the ReAct (Reasoning + Acting) approach, where the loop consists of:

• Think: LLM reads the conversation and decides its action

• Act: Calls a tool if required

• Observe: Reads the tool results

• Repeat: Goes back to the ‘Think’ step until a final answer is generated

In our case, the agent runtime takes the conversation history, builds the system prompt using the context builder, sends it to an LLM, and reads the response.

If an LLM wants to call a tool, the runtime executes that tool using the Skill loader. It then gives the tool result to the LLM and runs the loop again.

When the LLM gives a final response, this is returned to the user.

The loop runs for a maximum of 5 turns to avoid getting stuck in an infinite loop in case the LLM cannot find an answer and keeps making repeated tool calls.

# ./agent_runtime.py

import json
import httpx
from context_builder import build_system_prompt

# Max times the agent can call tools before stopping
MAX_TOOL_ROUNDS = 5

class AgentRuntime:
    def __init__(self, provider, model, api_key, skills, memory):
        self.provider = provider  # LLM provider (we use "anthropic")
        self.model = model        # LLM to use (we use "claude-opus-4-6")
        self.api_key = api_key    # API key for the LLM provider
        self.skills = skills      # Skill loader instance
        self.memory = memory      # Memory store instance

    async def run(self, history, session_id, callbacks):
        # Callback to send the final response to the user (Defined in ./telegram_channel.py)
        on_token = callbacks.get("on_token")

        # Callback to notify the user when a tool is being used (Defined in ./telegram_channel.py)
        on_tool_use = callbacks.get("on_tool_use")

        # Build system prompt 
        system_prompt = build_system_prompt(self.skills.get_active_skills(), self.memory)

        # Convert session history to API message format
        messages = [{"role": m["role"], "content": m["content"]} for m in history]

        # Get tool definitions from all loaded skills
        tools = self.skills.get_tools()

        response = ""
        rounds = 0

        # ReAct loop that keeps going until LLM returns an answer or hits the limit
        while rounds < MAX_TOOL_ROUNDS:
            rounds += 1

            # Send context to LLM and get a result
            result = await self._call_anthropic(
                system_prompt=system_prompt,
                messages=messages,
                tools=tools if tools else None,
            )

            # If the LLM wants to use tools, execute them and loop back
            if result["tool_calls"]:
                # Add the LLM's tool request to the conversation
                messages.append(
                    {"role": "assistant", "content": result["raw_content"]}
                )

                # Run each tool and feed the results back
                for tool_call in result["tool_calls"]:
                    if on_tool_use:
                        await on_tool_use(tool_call["name"], tool_call["input"])

                    # Execute the tool through the skill loader
                    tool_result = await self.skills.execute_tool(
                        tool_call["name"],
                        tool_call["input"],
                        {"session_id": session_id, "memory": self.memory},
                    )

                    # Add tool result to conversation history so the LLM 
                    # can see it in the next round
                    messages.append({
                        "role": "user",
                        "content": [{
                            "type": "tool_result",
                            "tool_use_id": tool_call["id"],
                            "content": json.dumps(tool_result),
                        }],
                    })

                continue  # Start the next loop with the new tool results added

            # If no tools needed, send the final response to the user
            if result["text"]:
                if on_token:
                    await on_token(result["text"])
                response = result["text"]
            
            # Exit once we have a final non-tool response
            break  

        return response

    # Call the Anthropic Messages API
    async def _call_anthropic(self, system_prompt, messages, tools):
        # Request payload (Anthropic separates system prompt from messages)
        body = {
            "model": self.model,
            "max_tokens": 4096,
            "system": system_prompt,
            "messages": messages,
        }

        # Add tool definitions for the loaded Skills
        if tools:
            body["tools"] = [{
                "name": t["name"],
                "description": t["description"],
                "input_schema": t["parameters"],
            } for t in tools]

        # Make async HTTP request to Anthropic API
        try:
            async with httpx.AsyncClient(timeout=120) as client:
                res = await client.post(
                    "https://api.anthropic.com/v1/messages",
                    headers={
                        "Content-Type": "application/json",
                        "x-api-key": self.api_key,
                        "anthropic-version": "2023-06-01",
                    },
                    json=body,
                )
        except httpx.ConnectError as e:
            raise Exception(f"Could not connect to Anthropic API: {e}")
        except httpx.TimeoutException as e:
            raise Exception(f"Anthropic API timed out: {e}")

        # Throw if the API returned an error
        if res.status_code != 200:
            raise Exception(f"Anthropic API error ({res.status_code}): {res.text}")

        data = res.json()
        text_parts = []
        tool_calls = []

        # Response can contain text blocks, "tool_use" blocks, or both
        for block in data["content"]:
            if block["type"] == "text":
                text_parts.append(block["text"])
            elif block["type"] == "tool_use":
                tool_calls.append({
                    "id": block["id"],
                    "name": block["name"],
                    "input": block["input"],
                })

        # Return normalized output
        return {
            "text": "".join(text_parts),
            "tool_calls": tool_calls or None,
            "raw_content": data["content"],
        }

9. Setting Up the Telegram Channel

The Telegram channel:

• Listens for messages from the user on Telegram chat

• Passes them through the LLM to get a response

• Sends the reply back to the user on the chat

Alongside this, it uses the Session manager to track each user’s conversation history separately.

# ./telegram_channel.py

import time
import asyncio
from telegram import Update
from telegram.ext import Application, MessageHandler, filters

# Translates between Telegram Bot API and Tiny-OpenClaw
class TelegramChannel:
    def __init__(self, token, agent, sessions):
        self.token = token   # Telegram bot token from @BotFather
        self.agent = agent   # Agent runtime instance
        self.sessions = sessions # Session manager instance

    # Start polling Telegram for new messages
    async def start(self):
        # Build the Telegram bot app using the bot token
        app = Application.builder().token(self.token).build()

        # Listen for messages and route them to _on_message
        app.add_handler(MessageHandler(filters.TEXT, self._on_message))

        # Initialize the bot and start checking for new messages
        await app.initialize()
        await app.start()
        await app.updater.start_polling()

        # Keep the bot running forever
        await asyncio.Future()

    # Called every time a user sends a message to the bot
    async def _on_message(self, update: Update, context):
        # Get the sender's unique chat ID 
        chat_id = str(update.effective_chat.id)

        # Get the text the user sent
        user_text = update.message.text

        # Ignore empty messages
        if not user_text:
            return

        # Get or create one session per Telegram chat using chat_id as the user identifier
        session_id = self.sessions.get_or_create_session(chat_id, "telegram")

        # Save user message to session history
        self.sessions.add_message(session_id, {
            "role": "user",
            "content": user_text,
            "timestamp": time.time(),
        })

        # Show "typing..." indicator in Telegram chat
        await update.effective_chat.send_action("typing")

        try:
            # Get full conversation history for this user
            history = self.sessions.get_history(session_id)

            full_response = ""

            # Callback that the LLM calls for each word it generates
            async def on_token(token):
                nonlocal full_response
                full_response += token

            # Refresh typing indicator when the agent uses a tool
            async def on_tool_use(name, input):
                await update.effective_chat.send_action("typing")

            # Run the ReAct loop
            await self.agent.run(history, session_id, {
                "on_token": on_token,
                "on_tool_use": on_tool_use,
            })

            # Send reply back to Telegram (split if over 4096 chars due to Telegram's limit)
            if full_response:
                for i in range(0, len(full_response), 4096):
                    await update.message.reply_text(full_response[i:i + 4096])

            # Save LLM response to session history
            self.sessions.add_message(session_id, {
                "role": "assistant",
                "content": full_response,
                "timestamp": time.time(),
            })

        # Send error message if something goes wrong
        except Exception as e:
            await update.message.reply_text(f"Error: {e}")

Before we start using the Telegram channel, we need to take the following steps:

• Download Telegram and search for @BotFather

• Send it a new message as /newbot to create a new Telegram bot

• Choose a name (“Tiny-OpenClaw”) and username (ending with ‘bot’)

• Copy the returned token from the chat and add it to the .env file as:

TELEGRAM_BOT_TOKEN=<your_telegram_bot_token>

10. Creating the Main Script

This script combines all the components that we previously created and makes everything work together.

# ./main.py

import asyncio
import os
from dotenv import load_dotenv

from memory_store import Memory
from session_manager import SessionManager
from skill_loader import SkillLoader
from agent_runtime import AgentRuntime
from telegram_channel import TelegramChannel

# Load environment variables
load_dotenv()

async def main():
    print("Tiny OpenClaw starting up...")

    # Create the Memory store
    memory = Memory()

    # Create the Session manager 
    sessions = SessionManager()

    # Load all Skills
    skills = SkillLoader()
    skills.load_from_directory(os.path.join(os.path.dirname(__file__), "skills"))

    # Create the agent runtime 
    agent = AgentRuntime(
        provider = os.getenv("MODEL_PROVIDER"),
        model = os.getenv("MODEL_NAME"),
        api_key = os.getenv("ANTHROPIC_API_KEY"), 
        skills = skills,
        memory = memory,
    )

    # Create the Telegram channel and connect it to the LLM agent and sessions
    telegram = TelegramChannel(
        token = os.getenv("TELEGRAM_BOT_TOKEN"),
        agent = agent,
        sessions = sessions,
    )

    print("\nTiny OpenClaw is running on Telegram.")
    print("\nGO CLAW!!! 🦞🦞🦞")

    # Start the Telegram bot 
    await telegram.start()

if __name__ == "__main__":
    asyncio.run(main())

11. Adding Environment Variables

Finally, the following environment variables are set up in the .env file.

ANTHROPIC_API_KEY=<your-key-here>

MODEL_PROVIDER=anthropic

MODEL_NAME=claude-opus-4-6

TELEGRAM_BOT_TOKEN=<your-telegram-token-here>

This completes our build!

12. Running Tiny-OpenClaw

We run Tiny-OpenClaw using the following command in the terminal.

uv run main.py

Tiny-OpenClaw in Action

Here are some screenshots of Tiny-OpenClaw performing different tasks using its Skills.

Super cool, right?

🥳 Congratulations on building your own tiny version of OpenClaw from scratch!

📦 Here is the GitHub repository that contains all the code for this project: Link

1. AlgoMaster 600: Added a new list with 300+ additional frequently asked problems covering most topics and patterns.

2. DSA Course: A complete course to learn DSA from scratch and prepare for coding interviews. It includes explanation to interview topics and a more granular classification of problems by patterns to help you build stronger intuition.

3. Company-wise Practice Page: A dedicated page to practice questions tailored to specific companies.

4. 600+ DSA Animations: Visualizations for most problems in the AlgoMaster list and key concepts.

5. AI powered Coding Interview Simulator: A new feature to practice in a realistic interview environment and receive AI-driven feedback on your approach, code quality, and overall problem-solving process.

I’ve kept a significant portion (~70%) of these resources as free to help the wider community. Many users have found even the free content to outperform most paid courses in both depth and quality.

For full access you can upgrade to premium plan at the current discounted price. The Premium plan includes access to all algomaster.io courses and features.

I’ve put a significant amount of effort in creating these resources and I hope you find them helpful.

What’s Inside?

AlgoMaster 600

I’ve added 300+ new problems to create a well-rounded, high-signal problem set covering all major patterns and difficulty levels. Each problem is carefully selected to give you both the breadth and depth needed to master coding interviews.

I’ve introduced a new frequency column to help you prioritize smarter by focusing on questions that appear more often in interviews.

You can now solve problems directly on the platform using the in-built code editor and judge. Currently it supports Java, Python, C++, C#, JavaScript, and TypeScript with plans to add more languages over time. If you prefer practicing on LeetCode, the original links are still available.

There’s also an Evaluate feature that reviews your solution, grades your code, and provides AI-driven feedback to help you improve.

DSA Course

Launching a complete, structured course designed to take you from fundamentals to interview-ready. The course breaks problems down by patterns and techniques so you learn how to recognize patterns easily in interviews.

Each topic includes curated practice problems, and every solution covers multiple approaches along with clear intuition, step-by-step algorithms, and animated walkthroughs to make concepts easy to understand.

Company-wise Practice Page

Introducing the company-wise practice page, where you can solve problems commonly asked by specific companies.

This helps you tailor your preparation to your target companies and get a clear sense of the types of questions they typically ask.

It’s especially useful in the final phase of preparation when you want to sharpen your focus. The company list will be updated regularly to stay current.

600+ DSA Animated Visualizations

Learning algorithms visually is one of the fastest ways to truly understand and retain them. You can grasp the core idea in minutes instead of watching an hour long video.

I’ve created 600+ animations that walk you through how data structures and algorithms work step by step.

These visualizations cover most problems in the AlgoMaster list along with core concepts, helping you build intuition much faster than static explanations.

AI powered Coding Interview Simulator

I’m excited to introduce an AI-powered coding interview simulator where you can practice in a realistic interview environment.

You can create and simulate real interview scenarios, solve problems under time pressure, and receive AI-driven feedback on your approach, code quality, and overall problem-solving process. This helps bridge the gap between practice and actual interviews.

It also includes a voice mode (premium feature), allowing you to explain your approach out loud while the AI interviewer responds in voice, just like a real interview. You can choose from different interviewer personas such as strict, balanced, or coaching.

If you get stuck, you can ask for hints during the session. After ending the interview, you’ll receive detailed feedback across multiple dimensions to help you improve.

If you have any suggestions or feedback, feel free to share. I’ll continue improving and expanding these resources over time.

For any questions related to content or subscription, please reply to this email or reach out at contact@algomaster.io

In this article, I’ll break down every major technology I used and, more importantly, why I chose it. If you’re planning to build your own platform, SaaS product, or side project, this could save you weeks of research and decision paralysis.

AlgoMaster is a Software Engineering interview preparation platform with interactive courses. It includes features like: algorithm visualizations, an in-browser code editor with remote execution, multiple AI-powered capabilities such as AI chatbot, system design interview practice, text-to-speech for lessons, and much more.

Building it taught me a lot about choosing the right tools, knowing when “good enough” is better than “perfect,” and shipping fast without compromising on what truly matters.

High-Level Architecture

Before diving into individual tools, here’s how everything fits together at a high level.

The architecture is intentionally simple. A Next.js frontend, deployed on Vercel, handles both the UI and API routes. Supabase powers the database, authentication, and file storage. Payload CMS manages all course content. Stripe handles payments. And a combination of OpenAI, Whisper, Elevanlabs and pgVector powers the AI features.

Every user request first hits Vercel’s edge network, where it is routed to the appropriate Next.js serverless function or static page. From there, the application communicates with the relevant backend services as needed.

Simple, but it works at scale.

Framework and Runtime

Next.js (React) + TypeScript

The entire platform is built as a Next.js 15 application using the App Router.

Next.js is an open-source, full-stack React framework that provides a structured approach along with powerful built-in features for building high-performance, scalable web applications.

I had not used Next.js before this project and had to learn it from scratch. After evaluating multiple options, it became clear that Next.js was the best fit for what I was building, both in terms of capabilities and ecosystem.

Here is what made Next.js the right choice:

• Full Stack Framework: It allows me to build both the frontend and backend in a single codebase, which simplifies development and reduces context switching.

• Server-side rendering (SSR) for SEO: For a content-heavy platform like AlgoMaster, SEO is critical. SSR ensures better indexing and faster initial load times.

• File-based routing: Routing is simple and intuitive. The file system directly maps to application routes, which improves developer experience and maintainability.

I use TypeScript across the entire codebase. For a project of this scale (1000+ code files), it is not optional.

Type safety has prevented countless bugs, especially at API boundaries where mismatches can easily occur. It also improves code readability, refactoring confidence, and long-term maintainability.

UI and Styling

shadcn/ui + Tailwind CSS

For the component library, I went with shadcn/ui. If you have not used it, shadcn is different from traditional component libraries like Material UI or Chakra.

Instead of installing a package and importing opaque components, you copy the component source code directly into your project. That means you own it completely. You can customize anything without fighting the library’s abstractions or overriding styles with hacky CSS specificity tricks.

Tailwind CSS handles all the styling. I had used plain CSS, CSS Modules, and styled-components on previous projects, and Tailwind was the clear winner for speed. Your design decisions live right where your markup is, and you’re never hunting through a separate CSS file.

Database and Authentication

Supabase (PostgreSQL + Auth + Storage)

Choosing Supabase was one of the most important decisions I made. As a solo developer, I needed a solution that could handle the database, authentication, and file storage without stitching together multiple services.

Supabase provides a full PostgreSQL database with a clean dashboard, built-in authentication (email, Google, GitHub OAuth), and S3-compatible storage for assets.

It also includes an interactive SQL editor, which makes it easy to run queries, debug issues, and inspect data directly without leaving the dashboard.

To improve performance for global users, I’ve configured a read replica alongside the primary database. This helps reduce latency for read-heavy operations across different regions.

One of the biggest advantages is Row-Level Security (RLS). I’ve configured RLS on sensitive tables so that even if someone attempts to access data via a direct API request, they can only see their own data.

Supabase makes this straightforward. You define SQL policies once, and they are enforced at the database level, which adds a strong layer of security without additional backend complexity.

Content Management

Payload CMS

This was one of the hardest parts to figure out. I spent a significant amount of time exploring different CMS options and even tried building a custom solution from scratch before finally settling on Payload.

The platform handles a large amount of structured content: courses, chapters, lessons, code examples, quizzes, and diagrams. I needed a CMS that could model complex relationships, remain developer-friendly, and be self-hosted.

Payload CMS checked all the boxes.

It is a headless, TypeScript-native, API-first CMS. I define all content schemas directly in TypeScript, and Payload automatically generates the admin panel along with REST and GraphQL APIs.

The admin panel is where all course content is created and managed, which makes the workflow smooth and centralized. I’ve defined multiple custom blocks to support different content components such as code snippets, callouts, diagrams, and more.

All Payload CMS data is stored in PostgreSQL under a separate schema, keeping it isolated from the main application data.

The Payload application itself is deployed separately on Vercel, allowing it to scale independently from the main platform.

Payments

Stripe

All payments are handled through Stripe.

The integration works like this: when a user subscribes, Stripe creates a subscription and sends a webhook to my Next.js API route. The webhook handler then updates the user’s entitlements in Supabase, granting access to premium features.

When a subscription is cancelled or expires, another webhook fires, and access is automatically revoked.

The interesting part was handling multi-currency support. I have users across 50+ countries, so displaying localized pricing was important. For this, I use Vercel’s geolocation headers to detect the user’s region and map it to the appropriate currency, enabling a seamless localized pricing experience.

AI Features

I’ve built 5+ AI-powered features into the platform, including:

• A lesson chatbot that answers questions based on the current chapter

• “Explain with AI” for content, code blocks, and diagrams

• An evaluation system for coding and LLD exercises

• A full system design practice mode with AI-driven feedback

Vercel AI SDK

The Vercel AI SDK acts an AI gateway that makes it easy to switch between different models. It also handles streaming responses seamlessly between the model APIs and the client, which improves the overall user experience.

OpenAI Models

I use OpenAI models such as GPT-5.4-mini and GPT-5.1 to power text-based AI features across the platform.

I use smaller models for high-frequency, lightweight tasks such as “Ask AI” and answer evaluation. For more complex tasks like system design evaluation and judging, I use larger, more capable models to get deeper reasoning and higher-quality outputs.

Voice input is powered by OpenAI Whisper. Users can speak their answers during interview simulations, and the audio is transcribed server-side.

pgVector

I use the pgVector extension in PostgreSQL to power the RAG-based chatbot experience across the platform.

At a high level, pgVector allows me to store and query embeddings directly inside my existing Postgres database. This removes the need for a separate vector database and keeps everything in a single, consistent system.

One important challenge with RAG systems is keeping embeddings up to date. To handle this, I’ve set up hooks in Payload CMS. Whenever a piece of content is created or updated, it automatically triggers re-generation of embeddings for that content.

ElevanLabs

Some users prefer listening over reading, especially during commutes. To support this, I use ElevenLabs api to generate audio versions of lessons.

Each audio file is generated once and then cached in Supabase Storage, so the cost is incurred only a single time per lesson.

While this feature is relatively expensive, the improvement in user experience makes it well worth it.

Claude Code

And yes, I use Claude Code (Anthropic’s AI coding tool) extensively for development. It has been one of the biggest productivity multipliers in building this platform.

Code Editor and Execution

I’ve built an in-browser code editor that allows users to write and execute code directly from the browser.

Monaco Editor

Every coding practice page uses Monaco Editor, the same editor that powers VS Code. It provides syntax highlighting, autocomplete, multi-language support, and a familiar developer experience.

Users can write and run code seamlessly without leaving the platform.

Docker

For code execution, I run a self-managed execution service on a DigitalOcean Droplet running Docker containers.

When a user clicks “Run,” their code is sent to the server, executed inside an isolated Docker container, and the output is returned. Each execution runs with strict time and memory limits to ensure reliability and fairness.

These containers are ephemeral. A new container is created for each execution and destroyed immediately afterward.

This level of isolation is critical because users can submit arbitrary code. It ensures that one user’s code cannot affect another user’s execution or access the underlying host system.

Visualizations & Diagrams

The platform includes 200+ interactive visualizations and simulations covering key interview topics such as DSA and System Design.

D3.js for Algorithm Visualizations

One of the core features of the platform is step-by-step algorithm visualization. These are built using D3.js, which provides fine-grained control over SVG elements, making it ideal for animating data structures and algorithms.

D3 does have a steep learning curve, but it unlocks a level of flexibility and precision that is hard to achieve with higher-level charting libraries.

Other Visualization Tools

• Mermaid for diagrams embedded in course content (architecture diagrams, flowcharts, sequence diagrams)

• Recharts for analytics dashboards and progress charts

• Excalidraw for the whiteboard feature, where users can sketch out system designs during practice sessions

Deployment and Monitoring

Vercel

The application is deployed on Vercel. For a Next.js app, this is the path of least resistance.

Every push to GitHub triggers an automatic build and deployment, and rolling back to a previous version is straightforward if something goes wrong.

I don’t manage any servers myself. Vercel handles infrastructure and auto-scaling out of the box. When traffic spikes, serverless functions scale automatically without any manual intervention.

To control costs and prevent abuse, I’ve configured rate limits and spending limits.

PostHog for Analytics

PostHog is used for product analytics, including tracking page views, active users, and overall user behavior.

It is open-source, self-hostable, and offers a generous free tier, although I currently use their cloud version.

PostHog also supports feature flags, which I plan to use for gradual rollouts. This will allow me to release new features to a subset of users first, validate them in production, and then roll them out to everyone with confidence.

Other Notable Tools

A few more tools that are worth mentioning:

Resend

Used for transactional emails such as login links and comment reply notifications. It has a clean API, reliable deliverability, and a generous free tier, which makes it a great fit.

BlockNote

Powers the notes feature. Users can take notes while going through courses, and BlockNote provides a Notion-like block editor that is easy to integrate with React. It supports rich text, code blocks, checklists, and more.

Zustand

Handles client-side state management. I had used Redux in a previous project and found it too verbose for my needs. Zustand is minimal, requires almost no boilerplate, and just works. It’s perfect for managing things like editor state, UI preferences, and quiz progress.

Final Thoughts

Most of these tools have generous free tiers. You can build something substantial without spending a dollar until you have real users. The barrier to starting is genuinely lower than it’s ever been.

What I’ve learned is this: the hard part is not choosing the perfect tech stack. It is building something people actually want, improving it consistently based on feedback, and showing up every day to make it better. The tech stack is just the vehicle.

You also don’t need to know everything before you start. I didn’t know 90% of the tools I’ve mentioned in this article when I began. I learned them along the way, one problem at a time.

I hope you found this useful. Let me know if you have any suggestions or recommendations.

Check it out here

These articles cover various topics including:

• Real-World System Design and Architecture

• AI/ML and Search

• Data Engineering

• Databases and Performance

• Infrastructure and Security

A lot of people tell you which engineering blogs to follow. Almost nobody tells you which articles are actually worth your time.

So I did the hard part: I went through the last 5–6 years of popular company engineering blogs and pulled out the articles that are genuinely worth reading.

My goal is to make this repo a one-stop resource for the most interesting engineering writing across the internet.

If you find it valuable, consider giving it a star (⭐️) and share it with others.

Give it a Star ⭐️

Contributions are welcome too. If you think a company or article is missing, feel free to open a pull request.

But like any technical topic, AI becomes much easier once you understand the fundamentals behind large language models (LLMs) and the modern tools built around them.

In this article, we will break down 20 of the most important AI concepts in the simplest way possible, with clear explanations and intuitive examples.

📣 Unblocked: The context layer your AI tools are missing (Sponsor)

Many developer tools promise context-aware AI, but having data access doesn’t automatically mean agents know when to use it.

Real context requires understanding. Unblocked synthesizes knowledge from your codebase, PRs, discussions, docs, project trackers, and runtime signals. It connects past decisions to current work, resolves conflicts between outdated docs and actual practice, respects data permissions, and surfaces what matters for the task at hand.

With Unblocked:

• Coding agents like Cursor, Claude, and Copilot generate output that aligns with your actual architecture and conventions

• Code review focuses on real bugs rather than stylistic nits

• You find instant answers without interrupting teammates

See how Unblocked works.

Get Started for Free

Foundations

1. Neural Network

At its core, a neural network is a stack of connected layers made up of simple units called neurons. Data enters through the input layer, moves through one or more hidden layers where the model learns useful patterns, and then produces a final prediction at the output layer.

A helpful way to picture this is as a series of refinement steps. The same input gets transformed again and again, with each layer extracting slightly higher-level features than the one before it. In image models, early layers often pick up simple signals like edges and textures. Deeper layers combine those signals into shapes and parts, and later layers can represent full objects.

The connections between neurons have weights, numbers that control how strongly one neuron influences another. Training is essentially the process of adjusting these weights so the network’s outputs become more accurate.

Modern large language models contain an enormous number of such weights, often in the tens or even hundreds of billions.

2. Transfer Learning

Training a neural network from scratch takes a huge amount of data and compute. Transfer learning changes the game. Instead of starting over, you take a model that has already been trained on a broad task and adapt it for a new, more specific one. Most of what the model learned still applies, so you get a strong head start.

A simple way to think about it is skill reuse. If you have already learned the basics, you can pick up a new variation much faster because the fundamentals do not need to be relearned. In the same way, a pretrained model already understands many general patterns in data, so fine-tuning it for your use case takes far less effort.

This is actually how most modern AI works. Someone trains a massive general-purpose model (the “foundation model”), and then you adapt it for your specific task.

Share

The Transformer Stack

3. Tokenization

Before a model can work with text, it first has to convert that text into smaller units called tokens. A token can be a full word, a part of a word, a punctuation mark, or sometimes even a single character. This is the model’s “alphabet” for reading and writing language.

For example, the word “happiness” might be split into subword tokens like “hap”, “pi”, and “ness”, while a common word like “cat” might remain a single token. In general, common words tend to map cleanly to one token, while longer or rarer words get broken into smaller pieces.

Why not just use whole words?

Because the number of possible words is enormous, and it keeps growing. Proper nouns, slang, typos, domain-specific terms, and words from different languages would explode the vocabulary size.

Tokenization solves this by using a fixed vocabulary (often around 30,000 to 100,000 tokens) built from common words and reusable subword chunks. That way, even if the model has never seen a word before, it can still represent it by combining familiar pieces.

4. Embeddings

Once text is split into tokens, each token gets converted into an embedding, a vector (basically a list of numbers) that captures what the token means.

You can think of embeddings as coordinates in a high-dimensional map. Words with similar meanings end up close to each other, while unrelated words are far apart. For example, “king” and “queen” are located near each other in this space, whereas “king” and “refrigerator” are much farther apart.

These vectors usually have hundreds or even thousands of dimensions. While that sounds abstract, those dimensions capture meaningful patterns. The difference between “king” and “queen” is similar to the difference between “man” and “woman.”

The model does not understand language symbolically the way humans do. Instead, it learns meaning through geometry, by organizing words in a space where relationships become distances and directions.

5. Attention

Here’s the problem: the meaning of a word depends on context. “Bank” means something different in “river bank” versus “bank account”. Embeddings alone don’t solve this because they start as fixed vectors per token.

Attention is the mechanism that addresses this. It lets each token look at every other token in the input and decide which ones matter. When processing “bank” in “I sat by the river bank”, the attention mechanism focuses on “river” and adjusts the representation of “bank” accordingly.

This was the key innovation that unlocked modern AI. Before attention, models processed words one at a time, left to right. Attention lets the model see everything at once and figure out what’s relevant.

6. Transformer

The transformer is the architecture that ties all of this together. It was introduced in a 2017 paper titled “Attention Is All You Need” and replaced the strictly sequential, word-by-word processing used in earlier models with attention as the central mechanism.

A transformer stacks multiple layers of attention and feed-forward networks. Each layer refines the representation of the input. Early layers tend to capture basic grammar. Middle layers pick up relationships between concepts. Later layers handle more complex reasoning.

One of the biggest advantages of transformers is that they process all tokens in parallel instead of one at a time. This makes training far more efficient on modern hardware like GPUs and enables models to scale to massive sizes. GPT, Claude, Gemini, Llama, and most other leading AI systems today are all built on transformer architectures.

In simple terms, text is converted into tokens, tokens become vectors, and stacked attention layers learn how those vectors relate and interact. That process forms the backbone of modern language models.

Large Language Models

7. LLM (Large Language Model)

A large language model (LLM) is essentially a transformer trained on an enormous amount of text, often hundreds of billions to trillions of tokens pulled from books, websites, code, and many other sources. The training objective sounds almost too simple: predict the next token.

That’s it. That’s the whole trick. But by doing this across trillions of examples, the model develops something that looks a lot like understanding, language, facts, reasoning patterns, even a degree of common sense. Most well-known systems today fall into this category, including GPT-style models, Claude, Gemini, and Llama.

The “large” part refers to the parameter count. Frontier models today have hundreds of billions of parameters, and training them costs tens of millions of dollars. But what you get is a model that can write code, answer questions, translate languages, and reason through problems it was never explicitly taught.

8. Context Window

The context window is the maximum number of tokens a model can process at once, including both your input and the model’s generated output. You can think of it as the model’s working memory.

Early GPT models had a context window of 4,096 tokens (roughly 3,000 words). That felt limiting fast. Current models have pushed way beyond that. Claude supports 200K tokens. Gemini goes up to 1M. More context means the model can handle longer documents, longer conversations, and more information when forming a response.

However, there is a trade-off. Bigger context windows require significantly more memory and compute, which increases cost and latency. And even with large windows, models do not treat every part of the input equally.

Research has shown that performance often drops for information buried in the middle of very long inputs, a phenomenon commonly referred to as “lost in the middle.”

9. Temperature

When an LLM generates the next token, it doesn’t just pick one. It calculates a probability for every token in its vocabulary. Temperature controls how it chooses from those probabilities.

At temperature 0, it always picks the most probable token. The result is deterministic, focused, and predictable. At temperature 1, it samples proportionally to the probabilities, so you get more variety and surprise. Above 1, things get increasingly random, more creative maybe, but also less coherent.

In practice, a few simple rules work well:

• Low temperature (0 to 0.3): best for precise tasks like code generation, structured extraction, summaries, and anything where correctness matters more than originality.

• Medium temperature (0.5 to 0.8): good for brainstorming, alternative phrasings, marketing copy, and creative writing where variety is useful.

• High temperature (1+): can be fun for playful ideation, but it often reduces coherence and can quickly produce nonsense, especially in longer outputs.

10. Hallucination

This is one of the most common issues people encounter with language models. A hallucination happens when an LLM produces something that sounds confident and believable, but is actually incorrect. It might reference a research paper that does not exist, invent a function in a software library, or present a fabricated statistic as if it were widely known.

Why does this happen?

Because LLMs are pattern completion engines at heart. They’re optimized to produce fluent, probable text, not to verify whether that text is true. If the most “natural” next sentence happens to be false, the model will produce it with the exact same confidence as a true one.

This makes hallucination one of the biggest practical challenges when using LLMs in real applications. Common ways to reduce it include retrieval-augmented generation (RAG), grounding responses in trusted source documents, and prompting the model to provide citations or acknowledge uncertainty.

Training and Optimization

At this point we have a powerful LLM, but it’s a generalist. How do you make it better at your specific task? And how do you shrink it enough to actually deploy?

These four techniques cover the spectrum from heavy customization to lightweight compression.

11. Fine-tuning

Fine-tuning starts with a pretrained model and continues training it on a smaller, task-specific dataset. The base model already understands general language patterns. Fine-tuning simply nudges it toward a particular domain, style, or behavior.

For example, if you want a model that performs well on medical question answering, you might fine-tune a general-purpose LLM on thousands of high-quality medical conversations or clinical explanations.

The trade-off is cost and infrastructure. Traditional fine-tuning updates most or all of the model’s parameters. That requires enough GPU memory to load the entire model along with optimizer states and gradients during training.

For a 70B parameter model, this typically means multiple high-end GPUs and significant compute resources. Fine-tuning can be powerful, but it is not lightweight.

12. RLHF (Reinforcement Learning from Human Feedback)

RLHF (Reinforcement Learning from Human Feedback) is one of the main techniques that turns “a model that predicts the next token” into “a model that feels helpful, polite, and safe to use.” It is a big reason modern chatbots feel like they are having a conversation, not just doing high-quality autocomplete.

At a high level, the process works like this:

1. Generate candidate answers. For a given prompt, the model produces multiple possible responses.

2. Humans rank them. Human reviewers compare those responses and rank them based on qualities like helpfulness, correctness, clarity, and safety.

3. Train a reward model. A separate model learns to predict which responses humans would prefer, based on those rankings.

4. Tune the LLM using that reward signal. The LLM is then optimized to produce answers that score higher according to the reward model.

This teaches the model behaviors that plain next-token prediction does not reliably produce: following instructions, refusing unsafe requests, being more balanced, and avoiding harmful or toxic directions.

Without RLHF (or other alignment methods), an LLM would be far more likely to continue text in whatever direction seems statistically plausible, even when that direction is unhelpful, misleading, or unsafe.

13. LoRA (Low-Rank Adaptation)

Fine-tuning every parameter in a large model, like a 70B parameter LLM, is extremely expensive. LoRA (Low-Rank Adaptation) takes a much more efficient approach.

Instead of updating the model’s original weights, it freezes them and adds small, trainable adapter matrices into selected layers. These adapters usually contain only about 0.1% to 1% of the total parameters.

The key insight is that the weight changes during fine-tuning tend to be “low-rank,” meaning they can be approximated by much smaller matrices without losing much quality. Instead of updating a 4096x4096 weight matrix, LoRA adds two small matrices (4096x8 and 8x4096) that together approximate the same change.

Why does this matter in practice?

You can fine-tune on a single GPU what would otherwise require a whole cluster. And you can swap different LoRA adapters in and out of the same base model, so you get multiple specialized versions without storing a full copy of the model for each one.

14. Quantization

Quantization is a way to make models smaller and cheaper to run by storing their weights with fewer bits. In full precision, weights are often stored as 32-bit floating point values. Quantization reduces that to 16-bit, 8-bit, or even 4-bit, cutting memory usage dramatically.

The basic math is straightforward: if you go from 32-bit to 4-bit, each weight uses 8× less memory, so the whole model becomes roughly 8× smaller.

For example, a 70B-parameter model can require well over 100GB of memory at full precision, but a 4-bit quantized version can fit into a few dozen GB. The quality drop is often smaller than you would expect, especially with 8-bit quantization, which tends to preserve performance well for many tasks.

This is one of the main reasons large models can run on consumer hardware. When you see someone running a 70B model on a desktop GPU or even a laptop, it is almost always a quantized checkpoint rather than the full-precision model.

Prompting and Reasoning

You’ve got a trained, optimized model. Now the question is: how do you actually get good output from it?

Turns out, a lot of it comes down to how you ask.

15. Prompt Engineering

Prompt engineering is the art of crafting your input to get better output. The same underlying question, phrased differently, can lead to dramatically different responses.

For example, a vague prompt like “explain databases” usually results in a high-level overview. But something more specific like “explain how B-tree indexes work in PostgreSQL, with a concrete example using a users table” gives the model clear direction.

Here are few techniques that consistently improve results:

• Role context: “You are a senior database engineer.”

• Few-shot examples: Provide sample inputs and outputs to show the format and depth you expect.

• Step-by-step decomposition: Break complex tasks into smaller, explicit steps.

• Constraints: Limit length, specify structure, or define the desired tone.

Prompt engineering is not a workaround. It is the primary interface for interacting with LLMs. The difference between a vague prompt and a carefully constructed one can mean the difference between shallow, generic output and something that is accurate, structured, and production-ready.

16. Chain of Thought (CoT)

Chain of thought is a prompting technique where you ask the model to show its reasoning step by step before giving a final answer. Simple idea, but it makes a surprisingly big difference on math, logic, and multi-step reasoning.

Here’s a concrete example.

Direct prompt: “What is 47 x 23?”

The model might output 1,071 (wrong) because it’s pattern-matching rather than actually computing.

Chain of thought prompt: “What is 47 x 23? Think step by step.”

The model walks through: 47 x 20 = 940, 47 x 3 = 141, 940 + 141 = 1,081 (correct).

By making the model generate intermediate steps, you’re giving it “scratch space” to work through the problem instead of jumping straight to an answer. Research shows this can improve accuracy on reasoning benchmarks by 20-40%.

Better answers come from letting the model think out loud, rather than forcing it to jump straight to a conclusion.

Building AI Systems

Knowing individual concepts is useful, but real AI products are systems, not solo models. This last section covers the building blocks engineers use to put it all together.

17. RAG (Retrieval-Augmented Generation)

Remember the hallucination problem? RAG (Retrieval-Augmented Generation) is one of the most effective ways to reduce it.

The idea is simple. Before the model generates a response, the system first retrieves relevant documents from a knowledge base and inserts them into the prompt as context. The model then answers using that information, instead of relying only on what it learned during training.

For example, imagine a customer support bot. When a user asks about your refund policy, the system first fetches the actual policy document, then the model generates an answer based on what it reads. The response is grounded in real, up-to-date information rather than vague recollection.

What makes RAG especially powerful is that it separates knowledge from reasoning.

• The LLM handles understanding and explanation.

• Your document store provides the facts.

If the information changes, you do not need to retrain the model. You simply update the documents it retrieves. This makes RAG practical, scalable, and far more reliable for real-world applications where accuracy matters.

18. Vector Database

So how does RAG actually find the right documents? That is where vector databases come in. They store embeddings, the numerical vectors we discussed earlier, and allow you to search by meaning rather than exact keywords.

Here is how the flow works. Your documents are first split into smaller chunks. Each chunk is converted into an embedding, and those embeddings are stored in a vector database.

When a user asks a question, the query is also converted into an embedding. The database then searches for the stored vectors that are closest to the query vector and returns the most relevant chunks.

This creates a fundamentally different kind of search. A keyword search for “how to cancel my subscription” might miss a document titled “account termination process.” A vector search can still find it because the underlying meaning is similar, even though the wording is different.

Some widely used vector databases include Pinecone, Weaviate, Qdrant, and Chroma. PostgreSQL can also support vector search through the pgvector extension, which makes it possible to add semantic search capabilities to a familiar relational database.

19. AI Agents

An AI agent is an LLM that does more than generate text. It can take actions, make decisions, and interact with external tools to complete tasks. While a chatbot mainly responds with language, an agent can browse the web, run code, query databases, call APIs, and chain these actions together to achieve a goal.

Most agents follow a simple control loop:

1. Observe the current state or new information.

2. Think about what to do next.

3. Act by using a tool or taking a step.

4. Repeat until the task is complete.

The LLM serves as the decision-making engine that drives this loop.

For example, a coding agent might read a bug report, search the codebase for relevant files, analyze the logic, write a fix, run tests, see failures, revise the fix, and run the tests again until everything passes. Each step involves the model deciding what action to take next based on the latest results.

The biggest challenge is reliability. Every step has some chance of failure, and those risks multiply across long action chains. If a 10-step task has 95% accuracy per step, the chance of everything working perfectly end-to-end drops to about 60%.

That is why modern agent frameworks invest heavily in planning, validation, retries, and self-correction to keep multi-step workflows on track.

20. Diffusion Models

Diffusion models are the engine behind many modern image generators, including DALL·E, Midjourney, and Nano Banana (Gemini). The core idea is a bit counterintuitive: they learn to generate images by first learning how to corrupt them.

During training, you start with real images and gradually add random noise until the image becomes almost pure static. The model is then trained to reverse that process, step by step, learning how to remove a little noise at a time and reconstruct the original image.

At generation time, you flip the pipeline. You begin with pure noise, and the model iteratively denoises it into a coherent image, guided by your text prompt. Each step makes the image slightly more structured, typically over something like 20–50 denoising steps.

The term “diffusion” comes from physics, where randomness spreads through a medium like ink dispersing in water. In diffusion models, noise spreads through the image in a similar way, and the model learns the reverse trajectory: how to go from randomness back to signal.

This same idea now extends beyond images. Diffusion-style approaches are used for video generation, audio, 3D assets, and even scientific domains like molecule and protein structure generation.

Thank you for reading!

If you found it valuable, hit a like ❤️ and consider subscribing for more such content every week.

If you have any questions/suggestions, feel free to leave a comment.

Instead of scattering data across variables and wiring behavior through unrelated functions, you bundle state and behavior into self-contained units. That makes code easier to reason about, extend, test, and maintain as the project grows.

But OOP is not just about writing classes. It is about understanding a small set of core ideas that help you model complexity, control change, and avoid turning your codebase into a fragile mess.

In this article, we’ll cover 12 OOP concepts every developer should know, with real-world examples and code. These concepts also appear frequently in low-level design interviews. I’ve also included links to help you explore each concept in more depth.

Lets get started.

Building Blocks

1. Classes

A class is a blueprint that defines the structure and behavior of objects. It specifies what data something will hold (fields) and what actions it can perform (methods).

Real-World Analogy: Think of it like an architectural blueprint for a house. The blueprint specifies the number of rooms, doors, and windows. But you can’t live in a blueprint. You need to build an actual house from it.

public class User {
    private String username;
    private String email;
    private String role;

    public User(String username, String email, String role) {
        this.username = username;
        this.email = email;
        this.role = role;
    }

    public boolean isAdmin() {
        return "ADMIN".equals(role);
    }

    public String getDisplayName() {
        return username + " (" + role + ")";
    }
}

In the above example, the User class bundles username, email, and role together with the methods that operate on them.

But a class by itself doesn’t do anything. It’s just a template. To actually use it, you need to create objects.

2. Objects

An object is a concrete instance of a class. It has actual values for the fields defined in the class.

If the class is a template, each object is a filled-in copy. You can create many objects from the same class, and each one is independent.

// Creating objects from the User class
User alice = new User("alice", "alice@example.com", "ADMIN");
User bob = new User("bob", "bob@example.com", "DEVELOPER");
User carol = new User("carol", "carol@example.com", "DEVELOPER");

alice.isAdmin();          // true
bob.isAdmin();            // false
alice.getDisplayName();   // alice (ADMIN)

Each object has its own copy of the fields. Changing alice‘s role doesn’t affect bob. They’re independent instances built from the same template.

Classes and objects let you group related data and behavior together. But in larger systems, you often need to define what behaviors must exist without specifying how they work. That’s where interfaces come in.

Share

3. Interfaces

An interface is a contract. It defines a set of methods that a class must implement, without specifying how they should work.

Think about payment processing in an e-commerce app. You need to charge customers, but you don’t want to be locked into a single payment provider. So, you define a contract that says “any payment gateway must support charging and refunding,” and then Stripe, PayPal, Razorypay or any future provider can plug in.

public interface PaymentGateway {
    PaymentResult charge(String customerId, double amount);
    PaymentResult refund(String transactionId);
}

public class StripeGateway implements PaymentGateway {
    private String apiKey;

    public StripeGateway(String apiKey) {
        this.apiKey = apiKey;
    }

    @Override
    public PaymentResult charge(String customerId, double amount) {
        // Stripe-specific API call
        System.out.println("Charging $" + amount + " via Stripe");
        return new PaymentResult(true, "txn_stripe_123");
    }

    @Override
    public PaymentResult refund(String transactionId) {
        System.out.println("Refunding " + transactionId + " via Stripe");
        return new PaymentResult(true, transactionId);
    }
}

public class PayPalGateway implements PaymentGateway {
    @Override
    public PaymentResult charge(String customerId, double amount) {
        // PayPal-specific API call
        System.out.println("Charging $" + amount + " via PayPal");
        return new PaymentResult(true, "txn_paypal_456");
    }

    @Override
    public PaymentResult refund(String transactionId) {
        System.out.println("Refunding " + transactionId + " via PayPal");
        return new PaymentResult(true, transactionId);
    }
}

The beauty of interfaces is that your checkout service can work with PaymentGateway without knowing whether it’s talking to Stripe or PayPal. Swapping providers means changing one line of configuration, not rewriting your business logic.

Interfaces tell you what classes must do. The four pillars of OOP tell you how to design those classes well.

The Four Pillars

4. Encapsulation

Encapsulation is the practice of bundling data and methods together in a class while restricting direct access to the internal data. You expose a controlled public interface and hide everything else.

Consider a rate limiter. Other parts of your system only need to ask “can this user make another request?” They shouldn’t be able to directly mess with the internal counters or reset the time window.

Here’s what happens without encapsulation:

public class RateLimiter {
    public int requestCount;       // Anyone can modify directly
    public long windowStartTime;   // Anyone can reset the window
    public int maxRequests;
}

RateLimiter limiter = new RateLimiter();
limiter.requestCount = -100;       // Invalid state
limiter.windowStartTime = 0;       // Window broken

And with encapsulation:

public class RateLimiter {
    private int requestCount;
    private long windowStartTime;
    private final int maxRequests;
    private final long windowSizeMs;

    public RateLimiter(int maxRequests, long windowSizeMs) {
        this.maxRequests = maxRequests;
        this.windowSizeMs = windowSizeMs;
        this.windowStartTime = System.currentTimeMillis();
        this.requestCount = 0;
    }

    public boolean allowRequest() {
        resetWindowIfExpired();
        if (requestCount < maxRequests) {
            requestCount++;
            return true;
        }
        return false;
    }

    public int getRemainingRequests() {
        resetWindowIfExpired();
        return maxRequests - requestCount;
    }

    private void resetWindowIfExpired() {
        long now = System.currentTimeMillis();
        if (now - windowStartTime >= windowSizeMs) {
            requestCount = 0;
            windowStartTime = now;
        }
    }
}

Now nobody can corrupt the internal state. The only way to interact with the limiter is through allowRequest() and getRemainingRequests(). The window-reset logic is completely internal. If you later switch from a fixed window to a sliding window algorithm, none of the calling code needs to change.

Encapsulation hides a class’s internal data. But there’s a closely related concept that hides complexity at a higher level.

5. Abstraction

Abstraction is about hiding unnecessary complexity and exposing only what the user needs. While encapsulation hides data, abstraction hides implementation details.

Real-World Analogy: Think about sending a message through Slack. You type a message and hit send. Behind the scenes, there’s WebSocket management, message serialization, retry logic, delivery confirmation, and push notifications. You don’t deal with any of that. The complexity is abstracted away behind a simple action.

In code, abstraction typically uses abstract classes or interfaces to define simplified interactions:

public abstract class CloudStorage {
    // What the caller sees - one simple method
    public String upload(String fileName, byte[] data) {
        validate(fileName, data);
        String path = generatePath(fileName);
        String url = doUpload(path, data);
        logUpload(fileName, url);
        return url;
    }

    // Each provider implements its own upload logic
    protected abstract String doUpload(String path, byte[] data);

    private void validate(String fileName, byte[] data) {
        if (fileName == null || data.length == 0) {
            throw new IllegalArgumentException("Invalid file");
        }
    }

    private String generatePath(String fileName) {
        return "uploads/" + System.currentTimeMillis() + "/" + fileName;
    }

    private void logUpload(String fileName, String url) {
        System.out.println("Uploaded " + fileName + " to " + url);
    }
}

public class S3Storage extends CloudStorage {
    @Override
    protected String doUpload(String path, byte[] data) {
        // AWS SDK calls, multipart upload, encryption...
        return "https://s3.amazonaws.com/bucket/" + path;
    }
}

public class GcsStorage extends CloudStorage {
    @Override
    protected String doUpload(String path, byte[] data) {
        // Google Cloud SDK calls, resumable upload...
        return "https://storage.googleapis.com/bucket/" + path;
    }
}

The caller just invokes upload(). They don’t need to know about path generation, validation, or provider-specific SDK calls. All that complexity is abstracted away.

Abstraction simplifies how you interact with objects. But what if multiple classes share the same data and behavior? That’s where inheritance steps in.

6. Inheritance

Inheritance lets a new class (child) derive from an existing class (parent), inheriting its fields and methods. The child class can reuse the parent’s code, add new behavior, or override existing behavior.

In an event-driven system, every event needs a timestamp, an event ID, and a source. But each specific event type carries its own payload. Instead of duplicating the common fields in every event class, you define them once in a base class.

public class DomainEvent {
    protected String eventId;
    protected String source;
    protected long timestamp;

    public DomainEvent(String source) {
        this.eventId = UUID.randomUUID().toString();
        this.source = source;
        this.timestamp = System.currentTimeMillis();
    }

    public String getEventId() {
        return eventId;
    }

    public long getTimestamp() {
        return timestamp;
    }
}

public class UserRegisteredEvent extends DomainEvent {
    private String userId;
    private String email;

    public UserRegisteredEvent(String userId, String email) {
        super("user-service");
        this.userId = userId;
        this.email = email;
    }

    public String getUserId() {
        return userId;
    }
}

public class OrderPlacedEvent extends DomainEvent {
    private String orderId;
    private double totalAmount;

    public OrderPlacedEvent(String orderId, double totalAmount) {
        super("order-service");
        this.orderId = orderId;
        this.totalAmount = totalAmount;
    }

    public String getOrderId() {
        return orderId;
    }
}

UserRegisteredEvent and OrderPlacedEvent both get eventId, source, timestamp, and getEventId() from DomainEvent without writing that code again. They also add their own unique fields.

Use inheritance when there’s a clear “is-a” relationship. A UserRegisteredEvent is a DomainEvent. A StripeGateway is a PaymentGateway. Avoid inheriting just to reuse code. If there’s no natural “is-a” relationship, use composition instead.

Inheritance lets classes share structure and behavior. But what happens when you call the same method on different child classes and get different results?

That’s polymorphism.

7. Polymorphism

Polymorphism means “many forms.” It allows objects of different types to be treated through a common interface, with each type providing its own behavior.

There are two types:

• Compile-time (method overloading): same method name, different parameters

• Runtime (method overriding): same method signature, different implementations in child classes

Runtime polymorphism is the more powerful concept. Imagine a notification system that sends alerts through different channels:

public interface NotificationChannel {
    void send(String recipient, String message);
}

public class EmailChannel implements NotificationChannel {
    @Override
    public void send(String recipient, String message) {
        // SMTP setup, HTML formatting, attachment handling...
        System.out.println("Email to " + recipient + ": " + message);
    }
}

public class SlackChannel implements NotificationChannel {
    @Override
    public void send(String recipient, String message) {
        // Slack API call, channel lookup, markdown formatting...
        System.out.println("Slack to #" + recipient + ": " + message);
    }
}

public class SmsChannel implements NotificationChannel {
    @Override
    public void send(String recipient, String message) {
        // Twilio API, phone number validation, character limits...
        System.out.println("SMS to " + recipient + ": " + message);
    }
}

// Polymorphism in action
List<NotificationChannel> channels = List.of(
    new EmailChannel(), new SlackChannel(), new SmsChannel()
);

for (NotificationChannel channel : channels) {
    channel.send("ops-team", "Server CPU above 90%");
    // Each channel sends the alert its own way
}

The loop doesn’t know or care whether it’s sending an email, a Slack message, or an SMS. It calls send() on each one, and the right implementation runs automatically. If you add a PagerDutyChannel tomorrow, the loop works without any changes.

This is the real power of polymorphism: you can write code that works with abstractions, and it automatically handles new types as they’re added.

Now that we understand how individual classes are structured and designed, let’s look at how objects relate to each other.

Object Relationships

8. Association

Association represents a “knows-about” relationship between objects. Both objects exist independently. Neither owns or controls the other.

Think of a developer and a repository on GitHub. A developer contributes to multiple repositories, and a repository has multiple contributors. But if a developer deletes their account, the repository still exists. And if a repository is archived, the developer keeps working on other things.

public class Developer {
    private String username;
    private List<Repository> repositories;

    public Developer(String username) {
        this.username = username;
        this.repositories = new ArrayList<>();
    }

    public void contributeTo(Repository repo) {
        repositories.add(repo);
    }
}

public class Repository {
    private String name;
    private List<Developer> contributors;

    public Repository(String name) {
        this.name = name;
        this.contributors = new ArrayList<>();
    }

    public void addContributor(Developer dev) {
        contributors.add(dev);
    }
}

// Both objects are created independently
Developer dev = new Developer("alice");
Repository repo = new Repository("payment-service");

// They reference each other, but neither owns the other
dev.contributeTo(repo);
repo.addContributor(dev);

The key here is independence. Both Developer and Repository are created outside of each other and just hold references. Deleting one doesn’t affect the other.

Association is the most general type of relationship. But sometimes, one object is part of another. That brings us to aggregation.

9. Aggregation

Aggregation is a specialized form of association that represents a “has-a” relationship where the whole contains parts, but the parts can exist independently.

Think of a team and its microservices. A team owns multiple microservices, but if the team is reorganized, the services don’t disappear. They get reassigned to a different team.

public class Team {
    private String name;
    private List<Microservice> services;

    public Team(String name) {
        this.name = name;
        this.services = new ArrayList<>();
    }

    // Services are created outside and assigned to the team
    public void addService(Microservice service) {
        services.add(service);
    }

    public void removeService(Microservice service) {
        services.remove(service);
    }
}

public class Microservice {
    private String name;
    private String repoUrl;

    public Microservice(String name, String repoUrl) {
        this.name = name;
        this.repoUrl = repoUrl;
    }
}

// Microservice exists independently
Microservice paymentService = new Microservice("payment-service", "github.com/org/payments");

// Team references the service but doesn't own it
Team platformTeam = new Team("Platform");
platformTeam.addService(paymentService);

// Service can be reassigned to another team
Team checkoutTeam = new Team("Checkout");
checkoutTeam.addService(paymentService);

The team has services, but services have their own lifecycle. They exist before being assigned to a team and continue to exist after being reassigned.

In aggregation, parts can survive without the whole. But what if the parts are so tightly coupled to the whole that they shouldn’t exist independently?

That’s composition.

10. Composition

Composition is a strong form of “has-a” where the whole owns the parts entirely. When the whole is destroyed, the parts are destroyed with it. The parts have no meaning outside of the whole.

Think of an order and its line items. Each line item (2x T-Shirt, 1x Laptop) only exists as part of that specific order. If the order is cancelled and deleted, the line items go with it. A line item floating around without an order makes no sense.

public class Order {
    private String orderId;
    private List<LineItem> lineItems;  // Order creates and owns line items

    public Order(String orderId) {
        this.orderId = orderId;
        this.lineItems = new ArrayList<>();
    }

    // Order creates the line item internally
    public void addItem(String productId, String productName, int quantity, double price) {
        lineItems.add(new LineItem(productId, productName, quantity, price));
    }

    public double getTotal() {
        return lineItems.stream()
            .mapToDouble(LineItem::getSubtotal)
            .sum();
    }

    public void cancel() {
        lineItems.clear();  // Line items destroyed with the order
        System.out.println("Order " + orderId + " cancelled");
    }
}

public class LineItem {
    private String productId;
    private String productName;
    private int quantity;
    private double unitPrice;

    // Package-private: only Order should create line items
    LineItem(String productId, String productName, int quantity, double unitPrice) {
        this.productId = productId;
        this.productName = productName;
        this.quantity = quantity;
        this.unitPrice = unitPrice;
    }

    double getSubtotal() {
        return quantity * unitPrice;
    }
}

// Order creates line items internally - they don't exist outside
Order order = new Order("ORD-001");
order.addItem("SKU-100", "Mechanical Keyboard", 1, 149.99);
order.addItem("SKU-200", "USB-C Hub", 2, 39.99);
System.out.println(order.getTotal());  // 229.97
order.cancel();  // All line items destroyed

Notice the difference from aggregation: in composition, the whole creates its parts internally (new LineItem(...) inside addItem). In aggregation, parts are passed in from outside.

Composition is about ownership and lifecycle control. But not all relationships involve ownership. Sometimes one object just temporarily uses another.

That’s dependency.

11. Dependency

Dependency is the weakest relationship between classes. It represents a temporary “uses-a” connection where one class uses another, typically as a method parameter, local variable, or return type, but doesn’t hold a long-term reference to it.

Think of a deployment pipeline. The pipeline uses a logger to record what’s happening, but it doesn’t own the logger or keep it around as part of its state. It just uses it during execution and moves on.

public class DeploymentService {
    // Dependency: uses HttpClient temporarily, doesn't store it
    public DeploymentResult deploy(String serviceName, String version, HttpClient client) {
        String url = "https://deploy.internal/" + serviceName;
        HttpResponse response = client.post(url, Map.of("version", version));

        if (response.getStatusCode() == 200) {
            return new DeploymentResult(true, "Deployed " + serviceName + " v" + version);
        }
        return new DeploymentResult(false, "Deployment failed: " + response.getBody());
    }
}

public class HttpClient {
    public HttpResponse post(String url, Map<String, String> body) {
        // HTTP connection setup, request serialization, TLS...
        System.out.println("POST " + url);
        return new HttpResponse(200, "OK");
    }
}

// DeploymentService uses HttpClient but doesn't own or store it
DeploymentService deployer = new DeploymentService();
HttpClient client = new HttpClient();
deployer.deploy("payment-service", "2.4.1", client);

DeploymentService depends on HttpClient, but only during the deploy() call. It doesn’t store the client as a field. Once the method returns, the relationship is gone.

Dependency is the weakest of the object relationships. The last concept in our list brings us full circle, connecting interfaces back to the classes that implement them.

12. Realization

Realization is the relationship between an interface and the class that implements it. The class “realizes” the contract defined by the interface by providing concrete implementations of all its methods.

We already saw this with PaymentGateway in the interfaces section. Let’s look at another example, a cache store:

public interface CacheStore {
    void put(String key, String value, int ttlSeconds);
    String get(String key);
    void evict(String key);
}

public class RedisCache implements CacheStore {
    private String connectionUrl;

    public RedisCache(String connectionUrl) {
        this.connectionUrl = connectionUrl;
    }

    @Override
    public void put(String key, String value, int ttlSeconds) {
        // Redis SETEX command with TTL
        System.out.println("Redis SET " + key + " EX " + ttlSeconds);
    }

    @Override
    public String get(String key) {
        // Redis GET command
        System.out.println("Redis GET " + key);
        return null;  // Simplified
    }

    @Override
    public void evict(String key) {
        // Redis DEL command
        System.out.println("Redis DEL " + key);
    }
}

Each class promises to fulfill the CacheStore contract. Your application code depends on CacheStore, so you can use Redis in production, an in-memory map in tests, and Memcached in a different environment, all without changing a single line of business logic.

Realization is what makes polymorphism through interfaces possible. It’s the bridge between abstract contracts and concrete behavior.

The Big Picture

Here’s how all 12 concepts relate to each other:

These 12 concepts form the foundation of object-oriented design. You don’t need to use all of them in every project, but understanding each one and knowing when to apply it will make you a better software engineer and help you tackle Low-Level Design interviews with confidence.

Thank you for reading!

If you found it valuable, hit a like ❤️ and consider subscribing for more such content every week.

If you have any questions/suggestions, feel free to leave a comment.

It covers concurrency and synchronization fundamentals, multi-threading patterns, and 25 commonly asked interview problems organized by category, each with detailed explanations and implementations. The content supports 5 languages: Java, Python, C++, C#, and Go.

I’ve kept a meaningful portion of the course (around ~50%) as free. For full access, you can upgrade to premium plan.

Check it out here

This is in addition to my Low-Level Design course, which covers core OOP concepts, design patterns and 40 interview problems. I also updated my LLD github repository with concurrency related topics.

What’s Inside?

25 Interview Problems (and growing)

The course includes 25 concurrency interview problems, with plans to add more over time.

For each problem, you get:

• The core concurrency challenges

• Multiple synchronization approaches (so you learn trade-offs, not just one solution)

• Clean implementations across supported languages

Language Specific Deep-Dives

Concurrency is deeply language-dependent. Each language has its own primitives, libraries, and best practices.

That’s why the course includes dedicated deep-dive chapters for each language, covering the key concurrency primitives and standard libraries.

400+ Diagrams

Concurrency is easier to learn when you can visualize what threads are doing.

This course includes 400+ diagrams (flowcharts, sequence diagrams, state diagrams, and more) to make the behavior of threads, locks, and coordination mechanisms feel intuitive.

Quizzes and Simulations

There are quizzes after chapters to test and reinforce your understanding.

There are interactive simulations to help you better understand the multi-threading concepts. I plan to add more simulations in coming weeks.

Check it out here

For any questions related to content or subscription, please reply to this email or reach out at contact@algomaster.io

In this post Shayan will share top 7 graph algorithms to know if you are preparing for coding interviews.

Graphs come up in about 35-40% of coding interviews at major tech companies because so many real systems are graphs: social networks, map routing, dependency chains, web crawlers. If you don’t know core graph patterns, you’ll struggle in the interview.

I’ve seen candidates get stuck on problems like “Number of Islands” simply because they hadn’t practiced basic grid traversal. These problems become straightforward once you know the patterns.

In this post, I’ll show you 7 graph algorithms that cover about 85% of graph-related interview questions. For each one, you’ll learn what it does, when to use it, how it works, and which LeetCode problems to practice.

This post is based on Repovive's Graph Theory roadmap. Let's get into it.

TL;DR: Algorithm Reference Table

1. Breadth-First Search (BFS)

What it is: BFS explores a graph level by level. It visits every node at distance 1 from the start, then distance 2, then distance 3, and so on.

When to use it:

Use BFS when the problem is naturally about layers or minimum steps:

• Finding the shortest path in an unweighted graph

• Level-order traversal

• Finding all nodes within K distance

• Any problem that asks for “minimum steps” or “shortest path” without weights

How it works:

BFS uses a queue. You start by adding the source node. Then you repeat: remove the front node, process it, and add all its unvisited neighbors to the back of the queue.

The queue enforces the level-by-level order. By the time you reach a node, you’ve visited all closer nodes first. This guarantees the first path you find is the shortest.

queue = [start]
visited = {start}

while queue is not empty:
    node = queue.pop_front()
    for neighbor in node.neighbors:
        if neighbor not in visited:
            visited.add(neighbor)
            queue.push_back(neighbor)

Grid Problems (Flood Fill)

BFS works well on 2D grids.

Think of grids like this:

• Each cell is a node

• Its neighbors are usually up, down, left, right (sometimes diagonals too)

Problems like “Number of Islands” and “Rotting Oranges” are grid-based BFS.

For flood fill, you start at a cell and spread to all connected cells matching a condition. You stop at boundaries or cells that don’t match. This is the algorithm behind the paint bucket tool in image editors.

Practice these LeetCode problems:

• Shortest Path in Binary Matrix (Medium)

• Rotting Oranges (Medium)

• Number of Islands (Medium)

• 01 Matrix (Medium)

• Word Ladder (Hard)

2. Depth-First Search (DFS)

What it is: DFS explores a graph as deep as possible before it backtracks. If a node has multiple neighbors, DFS fully explores the first neighbor’s branch, then returns and tries the next.

When to use it:

DFS is the right tool when you care about reachability, structure, or exhaustive exploration, not minimum distance:

• Detecting cycles

• Finding connected components

• Path finding (when you don’t need the shortest path)

• Backtracking problems

• Tree traversals

How it works:

A good mental model is a maze.

You choose a path, keep walking, and mark where you’ve been. When you hit a dead end, you backtrack to the last fork and try a different direction.

DFS uses a stack:

• Either an explicit stack you manage yourself

• Or recursion, which uses the call stack implicitly

Because the “most recent” node is processed next, DFS naturally pushes deeper into the graph.

function dfs(node):
    if node in visited:
        return
    visited.add(node)

    for neighbor in node.neighbors:
        dfs(neighbor)

Cycle Detection

DFS is one of the most common ways to detect cycles, but the exact rule depends on the graph type (directed vs undirected graphs).

For undirected graphs: if you reach a visited node that isn’t your immediate parent, you’ve found a cycle.

For directed graphs: you use three states (unvisited, in-progress, completed). If you reach an in-progress node, you’ve found a back edge, which means a cycle.

// Directed graph cycle detection
state = [UNVISITED] * n

function hasCycle(node):
    state[node] = IN_PROGRESS

    for neighbor in node.neighbors:
        if state[neighbor] == IN_PROGRESS:
            return true  // cycle found
        if state[neighbor] == UNVISITED:
            if hasCycle(neighbor):
                return true

    state[node] = COMPLETED
    return false

Practice these LeetCode problems:

• Clone Graph (Medium)

• Number of Provinces (Medium)

• Max Area of Island (Medium)

• Course Schedule (Medium)

• All Paths From Source to Target (Medium)

3. Dijkstra’s Algorithm

What it is: Dijkstra’s Algorithm finds the shortest path in a weighted graph where all edge weights are non-negative. Unlike BFS, it works when edges have different costs.

When to use it:

Reach for Dijkstra when you see weights and the question is about minimum cost:

• Shortest path with weighted edges

• Navigation and routing (Google Maps)

• Network routing with latency costs

• Any problem mentioning “minimum cost path”

How it works:

BFS doesn’t work on weighted graphs because one step doesn’t equal one unit of distance. A direct path might cost 10 while a two-step path costs 2.

Dijkstra fixes this by always expanding the currently cheapest known node first:

• Maintain dist[node] = best known distance from the source

• Use a min-heap / priority queue keyed by distance

• Pop the node with the smallest distance, then relax its edges

If the graph has only non-negative weights, the first time a node is popped with its best distance, that distance is final.

dist = [infinity] * numNodes
dist[source] = 0
pq = [(0, source)]  // (distance, node)

while pq is not empty:
    d, node = pq.pop_min()

    if d > dist[node]:
        continue  // found a better path already

    for (neighbor, weight) in node.edges:
        newDist = d + weight
        if newDist < dist[neighbor]:
            dist[neighbor] = newDist
            pq.push((newDist, neighbor))

Sample Problem: Network Delay Time

You have n network nodes. You’re given travel times as directed edges (u, v, w) where w is the time. You send a signal from node k. How long until all nodes receive it?

To solve this, you run Dijkstra from node k. Your answer is the maximum distance among all reachable nodes. If any node is unreachable, you return -1.

Practice these LeetCode problems:

• Network Delay Time (Medium)

• Path with Minimum Effort (Medium)

• Cheapest Flights Within K Stops (Medium)

• Swim in Rising Water (Hard)

4. Topological Sort

What it is: Topological sort orders nodes in a Directed Acyclic Graph (DAG) so that for every edge u → v, node u appears before node v. In plain terms: it gives you an execution order that respects dependencies. That’s why it shows up so often in scheduling-style problems.

When to use it:

Topological sort is the default pattern when you see dependency language:

• Course scheduling with prerequisites

• Build systems and dependency resolution

• Task ordering

• Any problem that mentions “prerequisites” or “dependencies”

How it works (Kahn’s Algorithm):

Kahn’s algorithm is the BFS-style way to do topological sorting.

Key idea: A node’s in-degree is the number of edges pointing to it. If a node has in-degree 0, it has no dependencies and you can process it.

You start by adding all nodes with in-degree 0 to a queue. You process them one by one. When you process a node, you decrement the in-degree of its neighbors. If a neighbor’s in-degree drops to 0, you add it to the queue.

If you process all nodes, you have a valid topological order. If the queue empties before you’ve processed all nodes, you’ve found a cycle.

inDegree = count incoming edges for each node
queue = all nodes with inDegree 0
result = []

while queue is not empty:
    node = queue.pop()
    result.append(node)

    for neighbor in node.outgoing:
        inDegree[neighbor] -= 1
        if inDegree[neighbor] == 0:
            queue.push(neighbor)

if len(result) < numNodes:
    return "cycle detected"

Sample Problem: Course Schedule II

You have numCourses courses. Some have prerequisites: [0, 1] means you take course 1 before course 0. You need to return any valid order to finish all courses, or an empty array if impossible.

To solve this, you build a directed graph where edge b→a means “take b before a”. Then run Kahn’s algorithm. If you can’t process all courses, you’ve found a cyclic dependency.

Practice these LeetCode problems:

• Course Schedule (Medium)

• Course Schedule II (Medium)

• Alien Dictionary (Hard)

• Parallel Courses (Medium)

5. Union-Find (Disjoint Set Union)

What it is: Union-Find is a data structure for tracking a collection of elements split into disjoint (non-overlapping) sets. It supports two core operations:

• find(x): which set does x belong to?

• union(x, y): merge the sets containing x and y

Once you have these, you can answer connectivity questions like “are these two nodes connected?” efficiently.

When to use it:

Union-Find shines when you’re adding connections over time and need fast connectivity checks:

• Dynamic connectivity queries

• Detecting cycles in undirected graphs

• Kruskal’s MST algorithm

• Grouping elements as edges are added

How it works:

Each set has a leader (representative). Two elements are in the same set if they have the same leader. You store a parent array where parent[i] points to i’s parent. The root is the leader (where parent[i] = i).

To make operations extremely fast in practice, Union-Find uses two standard optimizations:

1. Path compression: When you find the leader, you make each node on the path point directly to the leader.

2. Union by rank/size: When merging two sets, attach the smaller tree under the larger one to keep trees shallow.

parent = [0, 1, 2, ..., n-1]  // each node is its own leader
rank = [0] * n

function find(x):
    if parent[x] != x:
        parent[x] = find(parent[x])  // path compression
    return parent[x]

function union(x, y):
    px, py = find(x), find(y)
    if px == py:
        return false  // already connected

    if rank[px] < rank[py]:
        parent[px] = py
    else if rank[px] > rank[py]:
        parent[py] = px
    else:
        parent[py] = px
        rank[px] += 1

    return true

Sample Problem: Redundant Connection

You have a graph that started as a tree (connected, no cycles), then one edge was added. You need to find the edge that can be removed to restore the tree.

To solve this using union find, process edges one by one. For each edge (u, v), you check if u and v are already connected using find(). If yes, this edge creates a cycle. If no, you union them. The first edge that connects already-connected nodes is your answer.

Practice these LeetCode problems:

• Redundant Connection (Medium)

• Number of Provinces (Medium)

• Accounts Merge (Medium)

• Satisfiability of Equality Equations (Medium)

6. Minimum Spanning Tree (MST)

What it is: A spanning tree connects all nodes in a graph using exactly n-1 edges with no cycles. The minimum spanning tree is the one with the smallest total edge weight.

When to use it:

MST comes up whenever you need to connect a set of nodes with minimum total cost:

• Connecting all nodes with minimum cost

• Network design (cables, roads, pipelines)

• Clustering algorithms

• Approximation algorithms for NP-hard problems

How it works (Kruskal’s Algorithm):

Kruskal’s is the most common MST approach in interviews because it’s simple and pairs naturally with Union-Find.

You sort all edges by weight. You process them in order. For each edge, you use Union-Find to check if it connects two different components. If yes, you add it to the MST. If no, you skip it to avoid a cycle.

edges.sort(by weight)
mst = []
uf = UnionFind(n)

for edge in edges:
    u, v, weight = edge
    if uf.find(u) != uf.find(v):
        uf.union(u, v)
        mst.append(edge)

    if len(mst) == n - 1:
        break

return mst

Sample Problem: Min Cost to Connect All Points

You’re given points on a 2D plane. The cost to connect two points is their Manhattan distance. You return the minimum cost to connect all points.

To solve this, you treat each pair of points as a potential edge. Generate all edges, sort by weight, and run Kruskal’s. The MST gives you the minimum total cost.

Practice these LeetCode problems:

• Min Cost to Connect All Points (Medium)

• Connecting Cities With Minimum Cost (Medium)

• Find Critical and Pseudo-Critical Edges in MST (Hard)

7. Bipartite Graph Check

What it is: A graph is bipartite if you can split its nodes into two groups such that every edge connects nodes from different groups. No edge is allowed within the same group.

A simple way to remember it: Can you 2-color the graph so that no two adjacent nodes share the same color?

When to use it:

Bipartite checks appear whenever the problem is about dividing things into two compatible sets:

• Team or group assignments

• Matching problems

• Checking for odd-length cycles (a graph is bipartite if and only if it has no odd-length cycles)

• Scheduling with conflicts

How it works:

You can use BFS or DFS to try 2-coloring the graph.

Pick a start node and assign it color 0. Assign all its neighbors color 1. Assign their neighbors color 0. Continue alternating.

If you ever find an edge where both endpoints have the same color, the graph is not bipartite.

color = [-1] * n  // uncolored

function isBipartite(start):
    queue = [start]
    color[start] = 0

    while queue is not empty:
        node = queue.pop()
        for neighbor in node.neighbors:
            if color[neighbor] == -1:
                color[neighbor] = 1 - color[node]
                queue.push(neighbor)
            else if color[neighbor] == color[node]:
                return false

    return true

Sample Problem: Is Graph Bipartite?

You’re given an undirected graph. You return true if it’s bipartite.

Because the graph may be disconnected, run BFS/DFS from every uncolored node:

• Start a new traversal, try to 2-color that component

• If any component fails, return false

• If all components succeed, the graph is bipartite

Practice these LeetCode problems:

• Is Graph Bipartite? (Medium)

• Possible Bipartition (Medium)

What to Do Next

You now have 7 algorithms that cover most graph problems in coding interviews. Here’s how to retain them:

1. Practice in order. Start with BFS and DFS. They’re the foundation the others build on.

2. Match patterns to algorithms. “Shortest path” without weights → BFS. “Prerequisites” or “dependencies” → topological sort. “Minimum cost to connect” → MST.

3. Implement from scratch. Don’t just read the code. Write it yourself. Debug it. That’s how you learn.

4. Practice with time limits. In interviews, you have 20-30 minutes per problem. Get comfortable working under that constraint.

For a structured approach to learn, feel free to take a look at our roadmaps. It covers these algorithms plus topics like Strongly Connected Components, Lowest Common Ancestor, and Network Flow.

Behind these seamless experiences lies a key engineering decision: how does the server notify the client (or another system) when new data is available?

The traditional HTTP was built around a simple request-response flow: the client asks, the server answers. But in real-time systems, the server often needs to push updates proactively, sometimes continuously.

That’s where communication models like Long Polling, Server-Sent Events (SSE), WebSockets, and Webhooks come in.

In this article, we’ll break down how each one works, it’s pros and cons, where it fits best, and how to choose the right approach for a production system or a system design interview.

Let's start with the most straightforward approach.

1. Polling

Polling is the simplest approach to getting updates from a server. The client sends requests to the server at regular intervals, checking if anything has changed.

Think of it like refreshing your email inbox every few minutes to check for new messages.

How It Works

1. Client sends an HTTP request to the server

2. Server responds immediately with current data (or empty response)

3. Client waits for a fixed interval (e.g., 5 seconds)

4. Client sends another request

5. Repeat indefinitely

Notice something wasteful here? The client keeps asking even when nothing has changed. Three out of four requests in this diagram returned empty responses.

In real applications, this ratio is often much worse. You might make 100 requests before getting a single meaningful update.

Example: Weather Dashboard

Imagine you’re building a weather dashboard. Weather data doesn’t change that frequently, maybe every 15-30 minutes at most.

Polling makes sense here:

setInterval(async () => {
    const response = await fetch('/api/weather?city=london');
    const weather = await response.json();
    updateDashboard(weather);
}, 60000); // Poll every minute

Every minute, your client asks for the current weather. The server responds with temperature, humidity, conditions, and so on.

Pros

• Simple to implement: Just a regular HTTP request in a loop. No special protocols or libraries needed.

• Works everywhere: Any HTTP client can do polling. No firewall or proxy issues.

• Stateless: Each request is independent. The server doesn’t need to maintain any connection state.

• Easy to debug: Standard HTTP requests that show up in network logs and dev tools.

Cons

• Wasted requests: Most requests return empty responses when nothing has changed. This wastes bandwidth and server resources.

• High latency: Updates are delayed by the polling interval. If you poll every 10 seconds, updates can take up to 10 seconds to reach the client.

• Doesn’t scale: 10,000 clients polling every second means 10,000 requests per second, even when nothing is happening.

• Trade-off between latency and efficiency: Shorter intervals mean faster updates but more wasted requests. Longer intervals mean fewer requests but slower updates.

When to Use

• Low-frequency updates: Weather data, daily reports, or anything that changes infrequently

• Simple systems: MVPs, internal tools, or situations where simplicity matters more than efficiency

• Legacy compatibility: When you need to support older clients or environments that can’t use modern techniques

• Acceptable latency: When delays of several seconds (or minutes) are acceptable

Polling is a reasonable starting point, but you’ll quickly feel its limitations as your application grows. If you need faster updates without drowning your server in requests, that’s where long polling comes in.

2. Long Polling

Long polling improves on regular polling by having the server hold the request open until new data is available (or a timeout occurs). Instead of the client repeatedly asking “anything new?”, the server waits and responds only when there’s something to report.

This was the technique that powered early real-time applications like Facebook Messenger before WebSockets became widely supported.

How It Works

1. Client sends an HTTP request to the server

2. Server holds the connection open (doesn’t respond immediately)

3. When new data arrives, server sends the response

4. Client immediately sends another request

5. If no data arrives within the timeout period, server sends an empty response and client reconnects

The key insight is that the server only responds when it has something meaningful to say. This eliminates the wasted “nothing new” responses of regular polling.

Example: Chat Application

Consider a chat app built with long polling. When you open a conversation, your browser sends a request like:

GET /api/messages?conversation=123&after=msg_999

The server checks if there are any messages newer than msg_999. If not, instead of returning an empty response, it holds the connection and waits.

When someone sends a new message to that conversation, the server immediately responds with the new message. Your client receives it, renders it in the chat window, and immediately opens a new connection to wait for the next message.

There’s an important detail here: the timeout. HTTP connections can’t stay open forever. Proxies, load balancers, and browsers all have limits. So the server needs to respond eventually, even if nothing happened.

A typical timeout is 30 seconds. If 30 seconds pass with no new data, the server sends an empty response, the client immediately reconnects, and the wait continues.

Pros

• Near real-time: Updates arrive almost instantly when they happen, without waiting for a polling interval.

• Fewer wasted requests: Responses almost always contain useful data, not empty “nothing new” responses.

• Works through proxies and firewalls: Uses standard HTTP, so it works in restrictive network environments where WebSockets might be blocked.

• Simpler than WebSockets: No protocol upgrade, no special handling for connection state.

Cons

• Resource intensive: Each waiting client holds a connection open on the server. With 10,000 clients, you need 10,000 open connections.

• Timeout handling complexity: You need to handle timeouts, reconnection logic, and edge cases like the client receiving data just as the timeout expires.

• Head-of-line blocking: If multiple events happen quickly, they may get batched together or delivered out of order.

• HTTP overhead: Every response requires a new request, and each request carries HTTP headers. This overhead adds up.

When to Use

• Chat applications (historically): Before WebSocket support was universal, long polling powered most chat systems

• Fallback mechanism: When WebSockets aren’t available due to proxy or firewall restrictions

• Server-initiated updates: When clients mostly receive data rather than send it

• Moderate scale: Works well for hundreds or thousands of concurrent connections, but gets expensive at massive scale

Long polling feels like “almost real-time,” but it’s still request-response at heart. The client still initiates every exchange. What if the server could just push data to clients whenever it wants? That’s exactly what Server-Sent Events enable.

3. Server-Sent Events (SSE)

Read more

The key insight is that you should not over-engineer from the start. Start simple, identify bottlenecks, and scale incrementally.

In this article, I’ll walk you through 7 stages of scaling a system from zero to 10 million users and beyond. Each stage addresses the specific bottlenecks that show up at different growth points. You’ll learn what to add, when to add it, why it helps, and the trade-offs involved.

Whether you’re building an app or website, preparing for system design interviews, or just curious about how large-scale systems work, understanding this progression will sharpen they way you think about architecture.

Disclaimer: The user ranges and numbers mentioned in this article are approximate and intended to illustrate a scaling journey. Actual thresholds will vary depending on your product, workload characteristics, and traffic patterns.

Stage 1: Single Server (0-100 Users)

When you’re just starting out, your first priority is simple: ship something and validate your idea. Optimizing too early at this stage wastes time and money on problems you may never face.

The simplest architecture puts everything on a single server: your web application, database, and any background jobs all running on the same machine.

This is how Instagram started. When Kevin Systrom and Mike Krieger launched the first version in 2010, 25,000 people signed up on day one.

They didn’t over-engineer upfront. With a small team and a simple setup, they scaled in response to real demand, adding capacity as usage grew, rather than building for hypothetical future traffic.

What This Architecture Looks Like

In practice, a single-server setup means:

• A web framework (Django, Rails, Express, Spring Boot) handling HTTP requests

• A database (PostgreSQL, MySQL) storing your data

• Background job processing (Sidekiq, Celery) for async tasks

• Maybe a reverse proxy (Nginx) in front for SSL termination

All of these run on one virtual machine. Your cloud provider bill might be $20-50/month for a basic VPS (DigitalOcean Droplet, AWS Lightsail, Linode).

Why This Works for Early Stage

At this stage, simplicity is your biggest advantage:

• Fast deployment: One server means one place to deploy, monitor, and debug.

• Low cost: A single $20-50/month Virtual Private Server (VPS) can comfortably handle your first 100 users.

• Faster iteration: No distributed systems complexity to slow down development.

• Easier debugging: All logs are in one place, and there are no network issues between components.

• Full-stack visibility: You can trace every request end to end because there’s only one execution path.

The Trade-offs You’re Making

This simplicity comes with trade-offs you accept knowingly:

When to Move On

You’ll know it’s time to evolve when you notice these signs:

• Database queries slow down during peak traffic: The app and database compete for the same CPU and memory. One heavy query can drag down API latency for everyone.

• Server CPU or memory consistently exceeds 70-80%: You’re approaching the limits of what a single machine can reliably handle.

• Deployments require restarts and cause downtime: Even short interruptions become noticeable, and users start to complain.

• A background job crash takes down the web server: Without isolation, non-user-facing work can impact the user experience.

• You can’t afford even brief downtime: Your product has become critical enough that even maintenance windows stop being acceptable.

At some point, the server starts to struggle under the weight of doing everything. That’s when it’s time for your first architectural split.

Stage 2: Separate Database (100-1K Users)

As traffic grows, your single server starts struggling. The web application and database compete for the same CPU, memory, and disk I/O. A single heavy query can spike latency and slow down every API response.

The first scaling step is simple: separate the database from the application server.

This two-tier architecture gives you several immediate benefits:

• Resource Isolation: Application and database no longer compete for CPU/memory. Each can use 100% of their allocated resources.

• Independent Scaling: Upgrade the database (more RAM, faster storage) without touching the app server.

• Better Security: Database server can sit in a private network, not exposed to the internet.

• Specialized Optimization: Tune each server for its specific workload. High CPU for app server, high I/O for database.

• Backup Simplicity: Database backups don’t affect application performance since they run on a different machine.

Managed Database Services

At this stage, most teams use a managed database like Amazon RDS, Google Cloud SQL, Azure Database, or Supabase (I use Supabase at algomaster.io).

Managed services typically handle:

• Automated backups (daily snapshots, point-in-time recovery)

• Security patches and updates

• Basic monitoring and alerts

• Optional read replicas (we’ll cover these later)

• Failover to standby instances

The cost difference between self-hosting and managed is usually small once you factor in engineering time. A managed PostgreSQL instance might cost $50–$100/month more than a raw VM, but it can save hours of maintenance every week. Those hours are better spent shipping features.

The main reasons to self-manage a database are:

• Cost optimization at very large scale

• Specific configurations that managed services don’t support

• Compliance requirements that prohibit managed services

• You’re building a database product

For most teams, managed services are the right choice until your database bill grows into the thousands of dollars per month.

Connection Pooling

One often-overlooked improvement at this stage is connection pooling. Each database connection consumes resources:

• Memory for the connection state (typically 5-10MB per connection in PostgreSQL)

• File descriptors on both app and database servers

• CPU overhead for connection management

Opening a new connection is expensive too. Between the TCP handshake, SSL negotiation, and database authentication, you can add 50–100 ms of overhead per request.

A connection pooler like PgBouncer (for PostgreSQL) keeps a small set of database connections open and reuses them across requests.

With 1,000 users, you might have 100 concurrent connections hitting your API. Without pooling, that’s 100 database connections consuming resources. With pooling, 20-30 actual database connections can efficiently serve those 100 application connections through connection reuse.

Connection pooling modes:

• Session pooling: One pool connection per client connection (most compatible, least efficient)

• Transaction pooling: Connection returned to the pool after each transaction (best balance for most apps)

• Statement pooling: Connection returned after each statement (most efficient, but can break features)

Most applications work best with transaction pooling, which often improves connection efficiency by 3–5x.

Network Latency Considerations

Separating the database introduces network latency. When app and database were on the same machine, “network” latency was essentially zero (loopback interface). Now every query adds 0.1-1ms of network round-trip time.

For most applications, this is negligible. But if your code makes hundreds of database queries per request (an anti-pattern, but common), this latency adds up. The solution isn’t to put them back on the same machine, but to optimize your query patterns:

• Batch queries where possible

• Use JOINs instead of N+1 query patterns

• Cache frequently accessed data

• Use connection pooling to avoid repeated connection setup overhead

With the database on its own server, you’ve bought yourself room to grow. But you’ve also created a new single point of failure: the application server is now the weak link. What happens when it goes down, or when it simply can’t keep up with demand?

Stage 3: Load Balancer + Horizontal Scaling (1K-10K Users)

Read more

Getting good at DSA is less about how many problems you solve and more about how many patterns you truly understand.

Patterns help you solve a wide range of problems in less time because they train you to recognize the right approach, even for questions you have never seen before.

In this article, I’ll walk you through the 20 most important patterns that made learning DSA and preparing for coding interviews far less painful for me.

Even better, these are the same patterns that showed up again and again in my interviews, including at companies like Amazon and Google.

For each pattern, I’ll share:

• When to use it

• A reusable template

• A sample problem walkthrough

• Practice links to related LeetCode problems

This article is the essence of everything I have learned about DSA and LeetCode, distilled into one guide. I’ve also added links for each pattern so you can dive deeper when you’re ready.

If you want to explore more patterns and resources, check out: algomaster.io

Let’s get started.

Share

1. Prefix Sum

The Prefix Sum pattern involves preprocessing an array to create a new array where each element at index i represents the sum of all elements from the start up to i. This allows for O(1) sum queries on any subarray.

When to use

• Multiple sum queries on subarrays

• Finding subarrays with a target sum

• Calculating cumulative totals

Template

// Build prefix sum array
int[] prefix = new int[n + 1];
for (int i = 0; i < n; i++) {
    prefix[i + 1] = prefix[i] + nums[i];
}

// Query sum of range [left, right]
int rangeSum = prefix[right + 1] - prefix[left];

Sample Problem

Range Sum Query: Given an array nums, answer multiple queries about the sum of elements within a specific range [i, j].

Example:

• Input: nums = [1, 2, 3, 4, 5, 6], i = 1, j = 3

• Output: 9

Step-by-Step Walkthrough:

nums = [1, 2, 3, 4, 5, 6]

Step 1: Build prefix sum array
  prefix[0] = 0
  prefix[1] = 0 + 1 = 1
  prefix[2] = 1 + 2 = 3
  prefix[3] = 3 + 3 = 6
  prefix[4] = 6 + 4 = 10
  prefix[5] = 10 + 5 = 15
  prefix[6] = 15 + 6 = 21

  prefix = [0, 1, 3, 6, 10, 15, 21]

Step 2: Query sum for range [1, 3]
  sum = prefix[3 + 1] - prefix[1]
  sum = prefix[4] - prefix[1]
  sum = 10 - 1 = 9

Practice Problems

1. Range Sum Query - Immutable (LeetCode #303)

2. Contiguous Array (LeetCode #525)

3. Subarray Sum Equals K (LeetCode #560)

4. Product of Array Except Self (LeetCode #238)

2. Two Pointers

The Two Pointers pattern uses two pointers to traverse an array or list, typically from opposite ends or both moving in the same direction. It reduces time complexity from O(n^2) to O(n) for many problems.

When to use

• Finding pairs in sorted arrays

• Comparing elements from both ends

• Partitioning arrays

• Palindrome checks

Template

// Opposite direction (converging)
int left = 0, right = n - 1;
while (left < right) {
    if (condition_met) {
        // found answer
    } else if (need_larger_sum) {
        left++;
    } else {
        right--;
    }
}

// Same direction
int slow = 0;
for (int fast = 0; fast < n; fast++) {
    if (condition) {
        // process and move slow
        slow++;
    }
}

Sample Problem

Two Sum II: Find two numbers in a sorted array that add up to a target value. Return their indices.

Example:

• Input: nums = [1, 2, 3, 4, 6], target = 6

• Output: [1, 3] (indices of 2 and 4)

Step-by-Step Walkthrough:

nums = [1, 2, 3, 4, 6], target = 6

Step 1: left = 0, right = 4
  sum = nums[0] + nums[4] = 1 + 6 = 7 > 6
  Move right pointer left: right = 3

Step 2: left = 0, right = 3
  sum = nums[0] + nums[3] = 1 + 4 = 5 < 6
  Move left pointer right: left = 1

Step 3: left = 1, right = 3
  sum = nums[1] + nums[3] = 2 + 4 = 6 == target
  Found! Return [1, 3]

Practice Problems

1. Two Sum II - Input Array is Sorted (LeetCode #167)

2. 3Sum (LeetCode #15)

3. Container With Most Water (LeetCode #11)

4. Trapping Rain Water (LeetCode #42)

5. Valid Palindrome (LeetCode #125)

3. Sliding Window

The Sliding Window pattern maintains a window of elements and slides it across the array to find subarrays or substrings that satisfy certain conditions. It avoids recalculating overlapping parts of consecutive windows.

When to use

• Contiguous subarray/substring problems

• Finding maximum/minimum in window of size k

• Longest/shortest substring with certain properties

• Problems involving consecutive elements

Template

// Fixed-size window
int windowSum = 0;
for (int i = 0; i < n; i++) {
    windowSum += nums[i];
    if (i >= k - 1) {
        // process window
        result = Math.max(result, windowSum);
        windowSum -= nums[i - k + 1];
    }
}

// Variable-size window
int left = 0;
for (int right = 0; right < n; right++) {
    // expand window by including nums[right]

    while (window_condition_violated) {
        // shrink window from left
        left++;
    }

    // update result
}

Sample Problem

Maximum Sum Subarray of Size K: Find the maximum sum of any contiguous subarray of size k.

Example:

• Input: nums = [2, 1, 5, 1, 3, 2], k = 3

• Output: 9

Step-by-Step Walkthrough:

nums = [2, 1, 5, 1, 3, 2], k = 3

Step 1: Build initial window [2, 1, 5]
  windowSum = 2 + 1 + 5 = 8
  maxSum = 8

Step 2: Slide window to [1, 5, 1]
  windowSum = 8 - 2 + 1 = 7
  maxSum = max(8, 7) = 8

Step 3: Slide window to [5, 1, 3]
  windowSum = 7 - 1 + 3 = 9
  maxSum = max(8, 9) = 9

Step 4: Slide window to [1, 3, 2]
  windowSum = 9 - 5 + 2 = 6
  maxSum = max(9, 6) = 9

Result: 9

Practice Problems

1. Maximum Average Subarray I (LeetCode #643)

2. Longest Substring Without Repeating Characters (LeetCode #3)

3. Minimum Window Substring (LeetCode #76)

4. Permutation in String (LeetCode #567)

5. Sliding Window Maximum (LeetCode #239)

4. Fast & Slow Pointers

The Fast & Slow Pointers pattern (also called Tortoise and Hare) uses two pointers moving at different speeds. When there is a cycle, the fast pointer will eventually meet the slow pointer.

When to use

• Detecting cycles in linked lists or arrays

• Finding the middle of a linked list

• Finding the start of a cycle

Template

// Find middle
while (fast != null && fast.next != null) {
    slow = slow.next;
    fast = fast.next.next;
}
return slow; // middle node

// Cycle detection
ListNode slow = head, fast = head;
while (fast != null && fast.next != null) {
    slow = slow.next;
    fast = fast.next.next;

    if (slow == fast) {
        // cycle detected
        return true;
    }
}
return false; // no cycle

Sample Problem

Linked List Cycle: Detect if a linked list has a cycle.

Example:

• Input: head = [3, 2, 0, -4], tail connects to node index 1

• Output: true

Step-by-Step Walkthrough:

List: 3 -> 2 -> 0 -> -4 -> (back to 2)

Step 1: slow = 3, fast = 3
Step 2: slow = 2, fast = 0
Step 3: slow = 0, fast = 2 (wrapped around)
Step 4: slow = -4, fast = -4

slow == fast, cycle detected!

Practice Problems

1. Linked List Cycle (LeetCode #141)

2. Linked List Cycle II (LeetCode #142)

3. Happy Number (LeetCode #202)

4. Find the Duplicate Number (LeetCode #287)

5. Middle of the Linked List (LeetCode #876)

5. LinkedList In-place Reversal

This pattern reverses parts of a linked list without using extra space. It manipulates pointers to reverse the direction of links.

When to use

• Reversing a linked list or portion of it

• Reversing nodes in groups

• Checking for palindromes in linked lists

Template

// Reverse entire list
ListNode prev = null, curr = head;
while (curr != null) {
    ListNode next = curr.next;
    curr.next = prev;
    prev = curr;
    curr = next;
}
return prev; // new head

Sample Problem

Reverse Linked List II: Reverse the nodes of a linked list from position m to n.

Example:

• Input: head = [1, 2, 3, 4, 5], m = 2, n = 4

• Output: [1, 4, 3, 2, 5]

Step-by-Step Walkthrough:

Original: 1 -> 2 -> 3 -> 4 -> 5
Reverse positions 2 to 4

Step 1: Position prev before node 2
  prev = 1, curr = 2

Step 2: Move 3 after 1
  1 -> 3 -> 2 -> 4 -> 5

Step 3: Move 4 after 1
  1 -> 4 -> 3 -> 2 -> 5

Result: [1, 4, 3, 2, 5]

Practice Problems

1. Reverse Linked List (LeetCode #206)

2. Reverse Linked List II (LeetCode #92)

3. Swap Nodes in Pairs (LeetCode #24)

4. Reverse Nodes in k-Group (LeetCode #25)

5. Palindrome Linked List (LeetCode #234)

6. Frequency Counting

The Frequency Counting pattern uses hash maps or arrays to count occurrences of elements. It transforms O(n^2) lookup problems into O(n) by trading space for time.

When to use

• Finding duplicates or unique elements

• Checking if two collections have same elements

• Finding elements that appear k times

• Anagram problems

Template

// Using HashMap
Map<Integer, Integer> freq = new HashMap<>();
for (int num : nums) {
    freq.put(num, freq.getOrDefault(num, 0) + 1);
}

// Using array (when range is known)
int[] freq = new int[26]; // for lowercase letters
for (char c : str.toCharArray()) {
    freq[c - 'a']++;
}

// Finding element with specific frequency
for (Map.Entry<Integer, Integer> entry : freq.entrySet()) {
    if (entry.getValue() == target) {
        return entry.getKey();
    }
}

Sample Problem

Valid Anagram: Given two strings s and t, return true if t is an anagram of s.

Example:

• Input: s = "anagram", t = "nagaram"

• Output: true

Step-by-Step Walkthrough:

s = "anagram", t = "nagaram"

Step 1: Count frequencies in s
  freq = {a: 3, n: 1, g: 1, r: 1, m: 1}

Step 2: Decrement frequencies using t
  't' -> n: freq[n] = 1 - 1 = 0
  't' -> a: freq[a] = 3 - 1 = 2
  't' -> g: freq[g] = 1 - 1 = 0
  't' -> a: freq[a] = 2 - 1 = 1
  't' -> r: freq[r] = 1 - 1 = 0
  't' -> a: freq[a] = 1 - 1 = 0
  't' -> m: freq[m] = 1 - 1 = 0

Step 3: Check all frequencies are 0
  freq = {a: 0, n: 0, g: 0, r: 0, m: 0}
  All zero -> Return true

Practice Problems

1. Valid Anagram (LeetCode #242)

2. Group Anagrams (LeetCode #49)

3. Top K Frequent Elements (LeetCode #347)

4. First Unique Character in a String (LeetCode #387)

7. Monotonic Stack

A Monotonic Stack maintains elements in either increasing or decreasing order. As you iterate, you pop elements that violate the order, which reveals relationships between elements.

When to use

• Finding the next greater/smaller element

• Finding previous greater/smaller element

• Problems involving spans or ranges

• Histogram problems

Template

/// Next Greater Element (decreasing stack)
int[] result = new int[n];
Arrays.fill(result, -1);
Stack<Integer> stack = new Stack<>(); // stores indices

for (int i = 0; i < n; i++) {
    while (!stack.isEmpty() && nums[i] > nums[stack.peek()]) {
        int idx = stack.pop();
        result[idx] = nums[i];
    }
    stack.push(i);
}

Sample Problem

Next Greater Element: For each element in an array, find the next greater element. Output -1 if none exists.

Example:

• Input: nums = [2, 1, 2, 4, 3]

• Output: [4, 2, 4, -1, -1]

Step-by-Step Walkthrough:

nums = [2, 1, 2, 4, 3]
result = [-1, -1, -1, -1, -1]
stack = []

Step 1: i = 0, nums[0] = 2
  stack is empty, push 0
  stack = [0]

Step 2: i = 1, nums[1] = 1
  1 < nums[0]=2, push 1
  stack = [0, 1]

Step 3: i = 2, nums[2] = 2
  2 > nums[1]=1, pop 1, result[1] = 2
  2 <= nums[0]=2, push 2
  stack = [0, 2], result = [-1, 2, -1, -1, -1]

Step 4: i = 3, nums[3] = 4
  4 > nums[2]=2, pop 2, result[2] = 4
  4 > nums[0]=2, pop 0, result[0] = 4
  push 3
  stack = [3], result = [4, 2, 4, -1, -1]

Step 5: i = 4, nums[4] = 3
  3 < nums[3]=4, push 4
  stack = [3, 4]

Result: [4, 2, 4, -1, -1]

Practice Problems

1. Next Greater Element I (LeetCode #496)

2. Daily Temperatures (LeetCode #739)

3. Largest Rectangle in Histogram (LeetCode #84)

4. Trapping Rain Water (LeetCode #42)

5. Online Stock Span (LeetCode #901)

8. Bit Manipulation

Bit manipulation uses binary operations (AND, OR, XOR, NOT, shifts) to solve problems efficiently. XOR is particularly useful since a ^ a = 0 and a ^ 0 = a.

When to use

• Finding unique numbers (XOR)

• Checking power of 2

• Counting bits

• Generating subsets using bit masks

• Space optimization

Template

// Basic operations
int and = a & b;        // both bits 1
int or = a | b;         // either bit 1
int xor = a ^ b;        // bits different
int not = ~a;           // flip bits
int leftShift = a << n; // multiply by 2^n
int rightShift = a >> n;// divide by 2^n

// Check if bit i is set
boolean isSet = (n & (1 << i)) != 0;

// Set bit i
n = n | (1 << i);

// Clear bit i
n = n & ~(1 << i);

// Toggle bit i
n = n ^ (1 << i);

// Check if power of 2
boolean isPowerOf2 = (n > 0) && ((n & (n - 1)) == 0);

// Count set bits
int count = 0;
while (n > 0) {
    count += n & 1;
    n >>= 1;
}
// Or: Integer.bitCount(n);

// Find single number (XOR all elements)
int single = 0;
for (int num : nums) {
    single ^= num;
}

Practice Problems

1. Single Number (LeetCode #136)

2. Number of 1 Bits (LeetCode #191)

3. Counting Bits (LeetCode #338)

4. Power of Two (LeetCode #231)

5. Missing Number (LeetCode #268)

9. Top ‘K’ Elements

This pattern finds the k largest or smallest elements using heaps (priority queues). A min-heap of size k keeps track of k largest elements, and a max-heap keeps k smallest.

When to use

• Finding k largest/smallest elements

• Finding kth largest/smallest element

• Finding k most/least frequent elements

• Merging k sorted lists

Template

// K largest elements using min-heap
PriorityQueue<Integer> minHeap = new PriorityQueue<>();

for (int num : nums) {
    minHeap.offer(num);
    if (minHeap.size() > k) {
        minHeap.poll(); // remove smallest
    }
}
// minHeap now contains k largest elements
// minHeap.peek() is the kth largest

Sample Problem

Kth Largest Element: Find the kth largest element in an unsorted array.

Example:

• Input: nums = [3, 2, 1, 5, 6, 4], k = 2

• Output: 5

Step-by-Step Walkthrough:

nums = [3, 2, 1, 5, 6, 4], k = 2
Using min-heap of size k

Step 1: num = 3
  heap = [3]

Step 2: num = 2
  heap = [2, 3]

Step 3: num = 1
  heap = [1, 3, 2], size > k
  poll smallest: heap = [2, 3]

Step 4: num = 5
  heap = [2, 3, 5], size > k
  poll smallest: heap = [3, 5]

Step 5: num = 6
  heap = [3, 5, 6], size > k
  poll smallest: heap = [5, 6]

Step 6: num = 4
  heap = [4, 6, 5], size > k
  poll smallest: heap = [5, 6]

heap.peek() = 5 (kth largest)

Practice Problems

1. Kth Largest Element in an Array (LeetCode #215)

2. Top K Frequent Elements (LeetCode #347)

3. K Closest Points to Origin (LeetCode #973)

4. Find K Pairs with Smallest Sums (LeetCode #373)

5. Kth Largest Element in a Stream (LeetCode #703)

10. Overlapping Intervals

This pattern handles problems involving intervals that may overlap. The key insight is that after sorting by start time, two intervals [a, b] and [c, d] overlap if b >= c.

When to use

• Merging overlapping intervals

• Finding interval intersections

• Scheduling problems (meeting rooms)

• Inserting into sorted intervals

Template

// Sort by start time
Arrays.sort(intervals, (a, b) -> a[0] - b[0]);

// Merge overlapping intervals
List<int[]> merged = new ArrayList<>();
for (int[] interval : intervals) {
    if (merged.isEmpty() || merged.get(merged.size() - 1)[1] < interval[0]) {
        // no overlap, add new interval
        merged.add(interval);
    } else {
        // overlap, merge by extending end time
        merged.get(merged.size() - 1)[1] =
            Math.max(merged.get(merged.size() - 1)[1], interval[1]);
    }
}

Sample Problem

Merge Intervals: Given a collection of intervals, merge all overlapping intervals.

Example:

• Input: intervals = [[1,3], [2,6], [8,10], [15,18]]

• Output: [[1,6], [8,10], [15,18]]

Step-by-Step Walkthrough:

intervals = [[1,3], [2,6], [8,10], [15,18]]
(Already sorted by start time)

Step 1: interval = [1,3]
  merged is empty, add [1,3]
  merged = [[1,3]]

Step 2: interval = [2,6]
  last = [1,3], start = 2 <= end = 3
  Overlap! Merge: end = max(3, 6) = 6
  merged = [[1,6]]

Step 3: interval = [8,10]
  last = [1,6], start = 8 > end = 6
  No overlap, add [8,10]
  merged = [[1,6], [8,10]]

Step 4: interval = [15,18]
  last = [8,10], start = 15 > end = 10
  No overlap, add [15,18]
  merged = [[1,6], [8,10], [15,18]]

Practice Problems

1. Merge Intervals (LeetCode #56)

2. Insert Interval (LeetCode #57)

3. Non-overlapping Intervals (LeetCode #435)

4. Meeting Rooms (LeetCode #252)

5. Meeting Rooms II (LeetCode #253)

11. Modified Binary Search

This pattern adapts binary search to handle rotated arrays, finding boundaries, or searching for conditions rather than exact values.

When to use

• Searching in rotated sorted arrays

• Finding first/last occurrence of element

• Finding minimum/maximum satisfying a condition

• Peak finding problems

Template

// Standard binary search
int left = 0, right = n - 1;
while (left <= right) {
    int mid = left + (right - left) / 2;
    if (nums[mid] == target) return mid;
    else if (nums[mid] < target) left = mid + 1;
    else right = mid - 1;
}

// Find first occurrence
while (left < right) {
    int mid = left + (right - left) / 2;
    if (condition(mid)) right = mid;
    else left = mid + 1;
}

Sample Problem

Search in Rotated Sorted Array: Search for a target in a rotated sorted array.

Example:

• Input: nums = [4, 5, 6, 7, 0, 1, 2], target = 0

• Output: 4

Step-by-Step Walkthrough:

nums = [4, 5, 6, 7, 0, 1, 2], target = 0

Step 1: left = 0, right = 6, mid = 3
  nums[mid] = 7 != 0
  nums[left] = 4 <= nums[mid] = 7 (left half sorted)
  target = 0 not in [4, 7), search right
  left = 4

Step 2: left = 4, right = 6, mid = 5
  nums[mid] = 1 != 0
  nums[left] = 0 <= nums[mid] = 1 (left half sorted)
  target = 0 in [0, 1), search left
  right = 4

Step 3: left = 4, right = 4, mid = 4
  nums[mid] = 0 == target
  Found at index 4!

Practice Problems

1. Search in Rotated Sorted Array (LeetCode #33)

2. Find Minimum in Rotated Sorted Array (LeetCode #153)

3. Search a 2D Matrix (LeetCode #74)

4. Find Peak Element (LeetCode #162)

5. First Bad Version (LeetCode #278)

12. Binary Tree Traversal

Binary Tree Traversal visits all nodes in a specific order. The three main orders are preorder (root-left-right), inorder (left-root-right), and postorder (left-right-root).

When to use

• Processing tree nodes in specific order

• Building trees from traversals

• BST operations (inorder gives sorted order)

• Tree serialization/deserialization

Template

// Preorder (Root -> Left -> Right)
void preorder(TreeNode node) {
    if (node == null) return;
    process(node);        // visit root
    preorder(node.left);  // left subtree
    preorder(node.right); // right subtree
}

// Inorder (Left -> Root -> Right)
void inorder(TreeNode node) {
    if (node == null) return;
    inorder(node.left);   // left subtree
    process(node);        // visit root
    inorder(node.right);  // right subtree
}

// Postorder (Left -> Right -> Root)
void postorder(TreeNode node) {
    if (node == null) return;
    postorder(node.left);  // left subtree
    postorder(node.right); // right subtree
    process(node);         // visit root
}

Sample Problem

Inorder Traversal: Return the inorder traversal of a binary tree.

Example:

• Input: Tree with root = [1, null, 2, 3]

• Output: [1, 3, 2]

Step-by-Step Walkthrough:

Tree:
    1
     \
      2
     /
    3

Inorder: Left -> Root -> Right

Step 1: Start at 1
  No left child, visit 1
  result = [1]

Step 2: Go to right child 2
  Has left child 3, go left

Step 3: At node 3
  No left child, visit 3
  result = [1, 3]
  No right child, backtrack

Step 4: Back at node 2
  Left done, visit 2
  result = [1, 3, 2]
  No right child

Done: [1, 3, 2]

Practice Problems

1. Binary Tree Inorder Traversal (LeetCode #94)

2. Binary Tree Preorder Traversal (LeetCode #144)

3. Binary Tree Postorder Traversal (LeetCode #145)

4. Kth Smallest Element in a BST (LeetCode #230)

5. Validate Binary Search Tree (LeetCode #98)

13. Depth-First Search (DFS)

DFS explores as deep as possible along each branch before backtracking. It uses a stack (or recursion) to remember which nodes to visit next.

When to use

• Exploring all paths in a tree/graph

• Finding connected components

• Detecting cycles

• Topological sorting

• Path finding when all paths matter

Template

// DFS on a graph - visited tracking required
void dfs(int node, boolean[] visited, List<List<Integer>> graph) {
    visited[node] = true;

    // Process current node
    process(node);

    // Explore unvisited neighbors
    for (int neighbor : graph.get(node)) {
        if (!visited[neighbor]) {
            dfs(neighbor, visited, graph);
        }
    }
}

Sample Problem

Path Sum: Determine if the tree has a root-to-leaf path where values sum to a target.

Example:

• Input: root = [5, 4, 8, 11, null, 13, 4, 7, 2], targetSum = 22

• Output: true (path: 5 -> 4 -> 11 -> 2)

Step-by-Step Walkthrough:

Tree:
        5
       / \
      4   8
     /   / \
    11  13  4
   /  \      \
  7    2      1

Target = 22

DFS Path 1: 5 -> 4 -> 11 -> 7
  Sum = 5 + 4 + 11 + 7 = 27 != 22

DFS Path 2: 5 -> 4 -> 11 -> 2
  Sum = 5 + 4 + 11 + 2 = 22 == target
  Found! Return true

Practice Problems

1. Path Sum (LeetCode #112)

2. Path Sum II (LeetCode #113)

3. Clone Graph (LeetCode #133)

4. Course Schedule II (LeetCode #210)

5. Number of Islands (LeetCode #200)

14. Breadth-First Search (BFS)

BFS explores nodes level by level, visiting all neighbors before moving deeper. It uses a queue and guarantees the shortest path in unweighted graphs.

When to use

• Finding shortest path (unweighted)

• Level-order traversal

• Finding all nodes at distance k

• Spreading problems (rotting oranges, walls and gates)

Template

public void bfs(Node start) {
    // Handle edge case
    if (start == null) return;

    // Initialize queue and visited set
    Queue<Node> queue = new LinkedList<>();
    Set<Node> visited = new HashSet<>();

    // Add starting node
    queue.offer(start);
    visited.add(start);

    // Process nodes level by level
    while (!queue.isEmpty()) {
        Node current = queue.poll();

        // Process the current node
        process(current);

        // Add unvisited neighbors to queue
        for (Node neighbor : current.getNeighbors()) {
            if (!visited.contains(neighbor)) {
                visited.add(neighbor);
                queue.offer(neighbor);
            }
        }
    }
}

Sample Problem

Level Order Traversal: Return the level order traversal of a binary tree.

Example:

• Input: root = [3, 9, 20, null, null, 15, 7]

• Output: [[3], [9, 20], [15, 7]]

Step-by-Step Walkthrough:

Tree:
    3
   / \
  9  20
    /  \
   15   7

Step 1: Level 0
  queue = [3]
  Process 3, add children 9, 20
  result = [[3]]

Step 2: Level 1
  queue = [9, 20]
  Process 9 (no children)
  Process 20, add children 15, 7
  result = [[3], [9, 20]]

Step 3: Level 2
  queue = [15, 7]
  Process 15 (no children)
  Process 7 (no children)
  result = [[3], [9, 20], [15, 7]]

Practice Problems

1. Binary Tree Level Order Traversal (LeetCode #102)

2. Rotting Oranges (LeetCode #994)

3. Word Ladder (LeetCode #127)

4. Minimum Depth of Binary Tree (LeetCode #111)

5. Walls and Gates (LeetCode #286)

15. Shortest Path

Shortest path algorithms find the minimum distance between nodes. Dijkstra’s works for weighted graphs with non-negative weights, while Bellman-Ford handles negative weights.

When to use

• Finding minimum cost/distance paths

• Network routing problems

• Weighted graph traversal

• Problems with varying edge costs

Template

// Dijkstra's Algorithm using Priority Queue
int[] dist = new int[n];
Arrays.fill(dist, Integer.MAX_VALUE);
dist[source] = 0;

// PQ: (distance, node)
PriorityQueue<int[]> pq = new PriorityQueue<>((a, b) -> a[0] - b[0]);
pq.offer(new int[]{0, source});

while (!pq.isEmpty()) {
    int[] curr = pq.poll();
    int d = curr[0], node = curr[1];

    if (d > dist[node]) continue; // already processed

    for (int[] edge : graph.get(node)) {
        int neighbor = edge[0], weight = edge[1];
        int newDist = dist[node] + weight;

        if (newDist < dist[neighbor]) {
            dist[neighbor] = newDist;
            pq.offer(new int[]{newDist, neighbor});
        }
    }
}

Sample Problem

Network Delay Time: Find the time it takes for a signal to reach all nodes from a source node.

Example:

• Input: times = [[2,1,1], [2,3,1], [3,4,1]], n = 4, k = 2

• Output: 2

Step-by-Step Walkthrough:

Graph: 2 --(1)--> 1
       2 --(1)--> 3 --(1)--> 4
Source: node 2

Initial: dist = [INF, INF, 0, INF, INF] (1-indexed)
         pq = [(0, 2)]

Step 1: Process (0, 2)
  Neighbor 1: dist[1] = 0 + 1 = 1
  Neighbor 3: dist[3] = 0 + 1 = 1
  pq = [(1, 1), (1, 3)]

Step 2: Process (1, 1)
  No outgoing edges
  pq = [(1, 3)]

Step 3: Process (1, 3)
  Neighbor 4: dist[4] = 1 + 1 = 2
  pq = [(2, 4)]

Step 4: Process (2, 4)
  No outgoing edges

dist = [INF, 1, 0, 1, 2]
Max distance = 2

Practice Problems

1. Network Delay Time (LeetCode #743)

2. Cheapest Flights Within K Stops (LeetCode #787)

3. Path with Maximum Probability (LeetCode #1514)

4. Swim in Rising Water (LeetCode #778)

5. Path with Minimum Effort (LeetCode #1631)

16. Matrix Traversal

Matrix traversal uses DFS or BFS to explore 2D grids. The key is handling 4-directional (or 8-directional) movement and boundary checks.

When to use

• Grid-based problems (islands, regions)

• Flood fill algorithms

• Finding connected components in 2D

• Path finding in mazes

Template

// Direction arrays for 4 directions
int[] dx = {0, 0, 1, -1};
int[] dy = {1, -1, 0, 0};

// DFS on matrix
void dfs(int[][] grid, int i, int j, boolean[][] visited) {
    int m = grid.length, n = grid[0].length;

    // boundary and validity check
    if (i < 0 || i >= m || j < 0 || j >= n) return;
    if (visited[i][j] || grid[i][j] == 0) return;

    visited[i][j] = true;
    // process cell

    // explore 4 directions
    for (int d = 0; d < 4; d++) {
        dfs(grid, i + dx[d], j + dy[d], visited);
    }
}

// BFS on matrix
Queue<int[]> queue = new LinkedList<>();
queue.offer(new int[]{startRow, startCol});
visited[startRow][startCol] = true;

while (!queue.isEmpty()) {
    int[] cell = queue.poll();
    int i = cell[0], j = cell[1];

    for (int d = 0; d < 4; d++) {
        int ni = i + dx[d], nj = j + dy[d];
        if (ni >= 0 && ni < m && nj >= 0 && nj < n
            && !visited[ni][nj] && grid[ni][nj] == 1) {
            visited[ni][nj] = true;
            queue.offer(new int[]{ni, nj});
        }
    }
}

Sample Problem

Number of Islands: Count the number of islands (connected 1s) in a 2D grid.

Example:

• Input:

grid = [
  ["1","1","0","0","0"],
  ["1","1","0","0","0"],
  ["0","0","1","0","0"],
  ["0","0","0","1","1"]
]

• Output: 3

Step-by-Step Walkthrough:

Grid:
1 1 0 0 0
1 1 0 0 0
0 0 1 0 0
0 0 0 1 1

Step 1: Find '1' at (0,0)
  DFS marks connected cells: (0,0), (0,1), (1,0), (1,1)
  islands = 1

Step 2: Find '1' at (2,2)
  DFS marks: (2,2)
  islands = 2

Step 3: Find '1' at (3,3)
  DFS marks connected cells: (3,3), (3,4)
  islands = 3

Result: 3 islands

Practice Problems

1. Number of Islands (LeetCode #200)

2. Flood Fill (LeetCode #733)

3. Surrounded Regions (LeetCode #130)

4. Max Area of Island (LeetCode #695)

5. Pacific Atlantic Water Flow (LeetCode #417)

17. Backtracking

Backtracking explores all possible solutions by making choices, and undoes (backtracks) when a path leads to an invalid solution. It builds solutions incrementally.

When to use

• Generating all permutations/combinations/subsets

• Solving constraint satisfaction problems (N-Queens, Sudoku)

• Finding all paths meeting certain criteria

• String partitioning problems

Template

public void backtrack(State state, Choices choices, Results results) {
    // Base case: Is this a complete solution?
    if (isComplete(state)) {
        results.add(copy(state));  // Store the solution
        return;
    }

    // Recursive case: Try each available choice
    for (Choice choice : getAvailableChoices(state, choices)) {
        // 1. CHOOSE: Make the choice
        makeChoice(state, choice);

        // 2. EXPLORE: Recursively explore with this choice
        backtrack(state, choices, results);

        // 3. UNCHOOSE: Undo the choice (backtrack)
        undoChoice(state, choice);
    }
}

Sample Problem

Subsets: Generate all possible subsets of an array.

Example:

• Input: nums = [1, 2, 3]

• Output: [[], [1], [1,2], [1,2,3], [1,3], [2], [2,3], [3]]

Step-by-Step Walkthrough:

nums = [1, 2, 3]

backtrack([], start=0)
  add [] to result

  i=0: choose 1 -> [1]
    backtrack([1], start=1)
      add [1] to result

      i=1: choose 2 -> [1,2]
        backtrack([1,2], start=2)
          add [1,2] to result

          i=2: choose 3 -> [1,2,3]
            backtrack([1,2,3], start=3)
              add [1,2,3] to result
            unchoose 3 -> [1,2]
        unchoose 2 -> [1]

      i=2: choose 3 -> [1,3]
        backtrack([1,3], start=3)
          add [1,3] to result
        unchoose 3 -> [1]
    unchoose 1 -> []

  i=1: choose 2 -> [2]
    ...similar process

Result: [[], [1], [1,2], [1,2,3], [1,3], [2], [2,3], [3]]

Practice Problems

1. Subsets (LeetCode #78)

2. Permutations (LeetCode #46)

3. Combination Sum (LeetCode #39)

4. N-Queens (LeetCode #51)

5. Word Search (LeetCode #79)

18. Prefix Search (Trie)

A Trie (prefix tree) stores strings character by character, allowing efficient prefix lookups. Each node represents a character, and paths from root to nodes represent prefixes.

When to use

• Autocomplete and search suggestions

• Spell checking

• IP routing (longest prefix match)

• Word games (finding valid words)

Template

class TrieNode {
    TrieNode[] children = new TrieNode[26];
    boolean isEndOfWord = false;
}

class Trie {
    TrieNode root = new TrieNode();

    void insert(String word) {
        TrieNode node = root;
        for (char c : word.toCharArray()) {
            int idx = c - 'a';
            if (node.children[idx] == null) {
                node.children[idx] = new TrieNode();
            }
            node = node.children[idx];
        }
        node.isEndOfWord = true;
    }

    boolean search(String word) {
        TrieNode node = searchPrefix(word);
        return node != null && node.isEndOfWord;
    }

    boolean startsWith(String prefix) {
        return searchPrefix(prefix) != null;
    }

    private TrieNode searchPrefix(String prefix) {
        TrieNode node = root;
        for (char c : prefix.toCharArray()) {
            int idx = c - 'a';
            if (node.children[idx] == null) return null;
            node = node.children[idx];
        }
        return node;
    }
}

Sample Problem

Implement Trie: Implement a trie with insert, search, and startsWith methods.

Example:

Trie trie = new Trie();
trie.insert("apple");
trie.search("apple");   // returns true
trie.search("app");     // returns false
trie.startsWith("app"); // returns true

Step-by-Step Walkthrough:

Insert "apple":

  root
   |
   a (idx=0)
   |
   p (idx=15)
   |
   p (idx=15)
   |
   l (idx=11)
   |
   e (idx=4, isEndOfWord=true)

Search "apple":
  Traverse: a -> p -> p -> l -> e
  Node exists and isEndOfWord = true
  Return true

Search "app":
  Traverse: a -> p -> p
  Node exists but isEndOfWord = false
  Return false

StartsWith "app":
  Traverse: a -> p -> p
  Node exists (prefix found)
  Return true

Practice Problems

1. Implement Trie (LeetCode #208)

2. Word Search II (LeetCode #212)

3. Design Add and Search Words Data Structure (LeetCode #211)

4. Replace Words (LeetCode #648)

5. Longest Word in Dictionary (LeetCode #720)

19. Greedy

Greedy algorithms make locally optimal choices at each step, hoping to find a global optimum. They work when local optimal choices lead to global optimal solutions.

When to use

• Optimization problems with greedy choice property

• Interval scheduling

• Huffman coding

• Activity selection

• When proof by exchange argument works

Template

public Result solveGreedy(Input input) {
    // Step 1: Sort or organize input (if needed)
    sort(input, byGreedyCriterion);

    // Step 2: Initialize result and tracking variables
    Result result = initialResult();
    State state = initialState();

    // Step 3: Iterate and make greedy choices
    for (Element element : input) {
        if (canInclude(element, state)) {
            // Make the greedy choice
            result = update(result, element);
            state = updateState(state, element);
        }
    }

    return result;
}

Sample Problem

Jump Game: Determine if you can reach the last index starting from index 0.

Example:

• Input: nums = [2, 3, 1, 1, 4]

• Output: true

Step-by-Step Walkthrough:

nums = [2, 3, 1, 1, 4]

Track maxReach (farthest index we can reach)

Step 1: i = 0, nums[0] = 2
  maxReach = max(0, 0 + 2) = 2

Step 2: i = 1, nums[1] = 3
  i <= maxReach (1 <= 2)
  maxReach = max(2, 1 + 3) = 4

Step 3: i = 2, nums[2] = 1
  i <= maxReach (2 <= 4)
  maxReach = max(4, 2 + 1) = 4

Step 4: i = 3, nums[3] = 1
  i <= maxReach (3 <= 4)
  maxReach = max(4, 3 + 1) = 4

maxReach = 4 >= last index (4)
Return true

Practice Problems

1. Jump Game (LeetCode #55)

2. Jump Game II (LeetCode #45)

3. Gas Station (LeetCode #134)

4. Task Scheduler (LeetCode #621)

5. Partition Labels (LeetCode #763)

20. Dynamic Programming Patterns

Dynamic Programming (DP) solves problems by breaking them into overlapping subproblems and storing results to avoid recomputation. It works when problems have optimal substructure.

When to use

• Problems with overlapping subproblems

• Optimization (min/max) problems

• Counting problems (number of ways)

• Decision problems (can we achieve X?)

Common DP Patterns

1. Fibonacci Pattern (1D DP with previous states)

2. 0/1 Knapsack (include or exclude each item)

3. Longest Common Subsequence (2D DP on two sequences)

4. Longest Increasing Subsequence

You can find more DP patterns and how to approach them in this article.

Sample Problem

Climbing Stairs: Find the number of ways to climb n stairs, taking 1 or 2 steps at a time.

Example:

• Input: n = 4

• Output: 5

Step-by-Step Walkthrough:

n = 4

dp[i] = number of ways to reach step i
dp[i] = dp[i-1] + dp[i-2]
(we can reach step i from step i-1 or step i-2)

Base cases:
  dp[0] = 1 (one way to stay at ground)
  dp[1] = 1 (one way: take 1 step)

Step 2: dp[2] = dp[1] + dp[0] = 1 + 1 = 2
  Ways: [1,1], [2]

Step 3: dp[3] = dp[2] + dp[1] = 2 + 1 = 3
  Ways: [1,1,1], [1,2], [2,1]

Step 4: dp[4] = dp[3] + dp[2] = 3 + 2 = 5
  Ways: [1,1,1,1], [1,1,2], [1,2,1], [2,1,1], [2,2]

Result: 5 ways

Practice Problems

1. Climbing Stairs (LeetCode #70)

2. House Robber (LeetCode #198)

3. Coin Change (LeetCode #322)

4. Longest Common Subsequence (LeetCode #1143)

5. Longest Increasing Subsequence (LeetCode #300)

6. Partition Equal Subset Sum (LeetCode #416)

7. Edit Distance (LeetCode #72)

That’s it. Thanks for reading!

I’ve put together many more patterns and problems on my website. You can explore them here: algomaster.io

If this article helped you, give it a like and share it with others.

Share

But what actually happens when you run these commands? Where do your files go?How does Git track every change you have ever made without consuming gigabytes of storage?

Understanding Git’s internals helps you reason about your changes, debug issues faster, and use Git as the powerful tool it was designed to be.

In this article, we will explore:

• What Git really is under the hood

• Git’s object model: blobs, trees, and commits

• How Git uses SHA-1 hashes to store and address data

• The three areas: working directory, staging area, and repository

• How commits, branches, merges and rebases actually work

• How Git keeps repositories small

1. Distributed Version Control

Git is a distributed version control system created by Linus Torvalds in 2005 for Linux kernel development.

Older tools like CVS and SVN use a centralized model: one server holds the source of truth, and developers pull from and push to that central machine.

Git flips this model. In Git, every developer has a full copy of the repository, including the entire history.

This distributed setup gives Git a few key advantages:

• Work offline with full history

• No single point of failure

• Faster operations because most work happens locally

• Flexible workflows for teams and individuals

But how does Git store the full history without the repo becoming huge? To answer that, you need to understand the Git’s data model.

Share

2. Git’s Data Model

At its core, Git is a content-addressable filesystem. It stores data as objects, and each object is identified by a SHA-1 hash of its contents.

When you add a file to Git, it computes a 40-character hexadecimal SHA-1 hash of the file’s contents. This hash becomes the file’s unique address in Git’s database.

File contents: "Hello, World!"
SHA-1 hash:    5dd01c177f5d7d1be5346a5bc18a569a7410c2ef

Same content always produces the same hash. So two files with identical contents (even if they have different names) share the same hash.

Git stores the content once and references it multiple times, which helps repositories stay compact even across thousands of commits.

Git organizes everything into objects stored in its database. There are four types of objects, but three are essential for understanding how Git works: blobs, trees, and commits.

Blobs: Storing File Contents

A blob (binary large object) stores the raw contents of a file. Just the contents. No filename, no permissions, no timestamps, no metadata of any kind.

When you add README.md to Git, it creates a blob containing the file’s text. That blob has no idea it came from a file called README.md. It is simply a chunk of bytes with a SHA-1 hash computed from those bytes.

Why separate content from filename?

If the same config file is copied to three locations, a naive system stores three copies. Git stores one blob and references it three times, and these storage savings compound across the project’s history.

Of course, if blobs do not store filenames, Git still needs a way to represent folder structure. That is the job of trees.

Trees: Mapping Directory Structure

A tree represents a directory. It contains pointers to blobs (files) and other trees (subdirectories), along with filenames and permissions.

Tree: 4c5f8a2b9d3e7f1a6b0c8d5e2f9a4b7c3d6e0f1a
├── README.md      -> blob 5dd01c17...  (100644)
├── src/           -> tree 8a3b2c1d...
└── package.json   -> blob 7f2e3d4c...  (100644)

The tree acts as a directory listing. It says “there is a file called README.md, and its contents are stored in blob 5dd01c17.” The blob stores the data; the tree gives it a name and location.

If you rename a file without changing its contents, Git creates a new tree (with the new filename) pointing to the same blob. The actual file data is not duplicated.

Now we have blobs for content and trees for structure. But version control needs more: who made changes, when, and why. That is what commits provide.

Commits: Recording History

A commit captures a complete snapshot of your project at a specific moment in time. Every commit contains:

• A pointer to a tree (the root directory at that moment)

• Pointers to parent commits (the history leading to this point)

• Author information (who wrote the changes)

• Committer information (who applied the changes)

• Timestamps

• A commit message explaining the changes

Commit: abc123def456...
  tree:      def456...
  parent:    789012...
  author:    John <john@example.com> 1699900000 +0000
  committer: John <john@example.com> 1699900000 +0000

  Add login feature

When you run git commit, Git creates a new commit object. This commit points to a tree representing your project’s current state. The parent pointer links back to the previous commit, forming a chain. This chain is your project’s history.

The parent pointer is what makes Git a version control system rather than just a filesystem. By following parent pointers backward, Git can reconstruct any previous state of your project.

The following diagram shows how a complete snapshot looks in Git’s object model:

With blobs, trees, and commits, Git has everything it needs to store and track your project. But where do these objects actually live?

3. How Git Stores Objects

When you run git init, Git creates the .git directory with this structure:

.git/
├── HEAD              (contains: ref: refs/heads/main)
├── config            (repository configuration)
├── description       (used by GitWeb, rarely relevant)
├── hooks/            (scripts triggered by Git events)
├── info/             (exclude patterns, other info)
├── objects/          (the object database, initially empty)
│   ├── info/
│   └── pack/
└── refs/             (references to commits)
    ├── heads/        (branch pointers, initially empty)
    └── tags/         (tag pointers)

All Git objects live inside your repository’s .git/objects directory.

Git uses a simple organization scheme: the first two characters of an object’s hash become a subdirectory name, and the remaining 38 characters become the filename.

.git/objects/
├── 5d/
│   └── d01c177f5d7d1be5346a5bc18a569a7410c2ef  (blob)
├── 4c/
│   └── 5f8a2b9d3e7f1a6b0c8d5e2f9a4b7c3d6e0f1a  (tree)
├── a1/
│   └── b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0  (commit)
└── ...

This two-character prefix prevents any single directory from containing too many files, which could slow down filesystem operations.

Before writing an object to disk, Git also compresses it with zlib. A 1MB source file might shrink to ~100KB or less. Combine that with content-addressable deduplication (identical content stored once), and Git repositories stay surprisingly small even with long histories.

Inspecting Objects Directly

Git provides low-level commands to examine objects. These “plumbing” commands reveal what is happening under the hood:

# Determine an object's type (blob, tree, commit, or tag)
git cat-file -t 5dd01c17

# Display an object's contents
git cat-file -p 5dd01c17

# Examine what a commit contains
git cat-file -p HEAD

Try running git cat-file -p HEAD in a repository. You will see the tree pointer, parent pointer, author information, and commit message. Then run git cat-file -p on that tree hash to see the directory listing.

Objects explain how Git stores data, but they do not yet explain the day-to-day workflow. When you edit a file, stage it, and commit, you move data through three distinct areas.

Let’s look at those next.

4. The Three Areas

Git organizes your work into three separate areas. Understanding these areas is the key to understanding why Git commands behave the way they do.

Working Directory: Your Workspace

The working directory is what you see in your file explorer. These are actual files on your filesystem that you open in your editor, modify, and save.

The working directory is not Git. It is simply a checkout of one particular version of your project. Git can delete it and recreate it from any commit in seconds.

This is why you can switch branches instantly, even in large projects. Git is not moving files around; it is regenerating the working directory from its object database.

Staging Area: Your Draft

The staging area (also called the index) lives in a single file at .git/index. It represents the exact snapshot of what your next commit will contain.

When you run git add README.md, Git does two things:

1. Creates a blob object from the file’s current contents (or reuses an existing blob if the contents match)

2. Updates the index to associate the filename with that blob’s hash

Think of the staging area as a draft of your next commit. You can add files to it incrementally, remove files from it, and review exactly what is staged before committing.

This gives you precise control over what goes into each commit.

# See what is staged versus what is modified
git status

# See the actual diff of staged changes
git diff --staged

# Remove a file from staging (keep the working directory change)
git restore --staged README.md

Why have a staging area at all?

Imagine you changed five files. Three are part of a bug fix, and two are unrelated cleanup.

Without staging, you either commit everything together or do awkward manual juggling. With staging, you commit the bug fix first, then commit the cleanup separately. Your history stays clean and easy to follow.

Repository: The Source of Truth

The repository is the .git directory. It contains everything: the object database (all blobs, trees, commits), references (branches, tags), configuration, hooks, and more.

When you run git commit, Git:

1. Creates a tree object from the current index

2. Creates a commit object pointing to that tree, with the current HEAD as parent

3. Updates the current branch to point to this new commit

The repository is the source of truth for your project. The working directory and staging area are just convenient views into it. If you delete your working directory but keep .git, you can restore everything. If you delete .git, your history is gone.

Now that we understand where data lives, let’s understand what actually happens when you commit files.

5. How Commits Work

A Git commit is not a “bundle of changes.” It is a snapshot of your project at a moment in time, plus a pointer to its parent commit(s).

Let’s trace what Git creates as you commit.

Creating Your First Commit

echo "Hello" > hello.txt
git add hello.txt
git commit -m "Initial commit"

At this point, Git writes three objects:

1. Blob: the contents of hello.txt ("Hello\n")

2. Tree: a directory listing that maps hello.txt to that blob (and stores file mode like 100644)

3. Commit: points to the tree and stores metadata (author, timestamp, message)

The commit does not contain file contents directly. It contains a pointer to the root tree, and the tree points to blobs.

Creating a Second Commit

Now change the file and commit again:

echo "World" >> hello.txt
git commit -am "Add world"

What changes inside Git?

• hello.txt has new content, so Git creates a new blob for the new contents.

• Because the file now points to a different blob, Git creates a new tree.

• Git creates a new commit pointing to that new tree, and sets its parent to the previous commit.

Notice what did not happen:

• Git did not modify Blob A.

• Git did not overwrite Tree A.

• Git did not “update” Commit A.

Git objects are effectively immutable. New state means new objects, while unchanged objects are reused.

Also notice the storage efficiency: even though commits are “snapshots,” Git is not duplicating everything each time. Only objects that changed are new. Everything else is referenced again.

Snapshots, Not Diffs

A common misconception is that Git stores diffs between commits, like:

Commit 1 + Diff -> Commit 2 + Diff -> Commit 3 ...

That is not how Git works.

Git stores snapshots:

• Each commit points to a tree

• That tree represents the full directory state at that moment

• Git computes diffs only when you ask for them (for example git diff, git show, PR views)

So the internal model is closer to this:

Snapshot (Tree) A  -> Commit A
Snapshot (Tree) B  -> Commit B
Snapshot (Tree) C  -> Commit C

This is why operations like checkout are fast. Git does not replay every change from the beginning of time. It simply reads the tree for the commit you want and regenerates the working directory from that snapshot.

6. How Branches Work

Here is the fact that changes how you think about Git: a branch is just a pointer to a commit.

That is the entire implementation. A branch is a small file containing a 40-character commit hash. The file for your main branch lives at .git/refs/heads/main.

.git/refs/heads/main:    a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0
.git/refs/heads/feature: x9y8z7w6v5u4t3s2r1q0p9o8n7m6l5k4j3i2h1g0

Creating a branch is nearly instantaneous because Git only creates a tiny file. There is no copying of files, no duplicating history. Just a 41-byte file (40 characters plus a newline) pointing to an existing commit.

HEAD: Tracking Your Current Position

HEAD is a special reference that tells Git where you are. In most cases, HEAD points to a branch name rather than directly to a commit:

.git/HEAD: ref: refs/heads/main

This means: “you are on main.” Git resolves your current commit by following pointers: HEAD → main → commit → tree → files

When you create a new branch using git branch feature, Git creates .git/refs/heads/feature containing the current commit hash. No new commits, no copying.

When you switch branches with git checkout feature, Git updates HEAD to point to refs/heads/feature, then regenerates your working directory and index to match that branch’s commit.

Sometimes HEAD points directly to a commit hash instead of a branch name. This is called detached HEAD state. It happens when you checkout a specific commit by its hash or checkout a tag.

In this state, any new commits you create are not attached to a branch and can become “lost” if you switch away without creating a branch to preserve them.

How Commits Advance Branches

When you create a new commit while on a branch, Git advances that branch pointer.

The new commit (C4) has C3 as its parent. Then Git updates .git/refs/heads/main to contain C4’s hash. HEAD still points to main, but main now points to the new commit.

This pointer-based design explains why Git branching is so fast and cheap. There is no copying involved. Creating ten branches from the same commit means creating ten 41-byte files, all pointing to the same commit hash.

But branches diverge. Different developers make different changes on different branches. Eventually, those branches need to come back together. Let’s see how merging works.

7. How Merging Works

Merging combines the work from two branches into one. Git handles merging differently depending on how the branches have diverged.

Fast-Forward Merge: The Simple Case

The simplest merge happens when the target branch has not moved since the source branch was created. In this case, Git performs a fast-forward merge: it simply moves the target branch pointer forward to match the source branch.

No new commit is created. Git just updates the main branch pointer from C2 to C3. Fast-forward merges are instant and create a linear history.

Three-Way Merge: When Branches Diverge

When both branches have new commits since they diverged, Git performs a three-way merge. It needs three pieces of information:

1. The merge base: the common ancestor where the branches diverged

2. The current branch tip: where your branch is now (ours)

3. The other branch tip: what you are merging in (theirs)

Git compares both branch tips against the merge base to determine what changed on each side. Changes that only appear on one side are applied automatically. Changes that conflict (both sides modified the same lines) require manual resolution.

The resulting merge commit (C4) has two parents: C2 from main and C3 from feature. This preserves the complete history of both branches. You can trace back through either parent to see exactly what work happened on each branch.

Handling Conflicts

When Git cannot automatically merge (the same lines were changed differently on both sides), it marks the conflicts in your files:

<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> feature

Everything between <<<<<<< HEAD and ======= is from your current branch. Everything between ======= and >>>>>>> feature is from the branch being merged.

You resolve the conflict by editing the file to contain what you actually want, removing the conflict markers, then staging and committing.

Merging preserves the complete history of both branches, but it creates merge commits that can clutter the history. There is another way to integrate changes that results in a cleaner, linear history.

8. How Rebase Works

Rebasing is an alternative to merging that rewrites history to create a linear sequence of commits.

Instead of creating a merge commit that ties two branches together, rebase moves your commits to appear as if they were created on top of the target branch.

When you run git rebase main while on a feature branch, Git:

1. Finds the common ancestor of both branches

2. Saves the commits that are unique to your feature branch

3. Resets your branch to the tip of main

4. Replays your saved commits one by one on top

Notice that F1 and F2 become F1' and F2' after rebasing. The prime marks indicate these are new commits with different hashes. Even though the changes are identical, the commits have different parent pointers, which means different SHA-1 hashes.

The original commits still exist in the object database (and are recoverable via reflog) but are no longer reachable from any branch.

9. How Git Optimizes Storage

So far, we have discussed “loose objects”: individual files in .git/objects/ named by their hash. This is simple and fast for writing new objects, but it does not scale perfectly.

Two issues show up as a repo grows:

• Filesystem overhead: thousands (or millions) of tiny files can slow down filesystems.

• Wasted space across versions: even though Git stores snapshots, many snapshots differ only slightly.

Git solves both problems with pack files.

Pack Files

Instead of keeping every object as a separate file, Git periodically (during git gc, push, fetch, or clone) bundles many objects together into a pack:

.git/objects/pack/
├── pack-abc123def456.idx   (index for fast lookup)
└── pack-abc123def456.pack  (compressed objects with deltas)

• The .pack file holds the actual compressed, delta-encoded data.

• The .idx file is an index that lets Git locate any object inside the pack quickly.

This reduces file count dramatically and makes large repositories more efficient to store and transfer.

How packing saves space

When Git creates a pack, it applies three main optimizations:

1. Grouping: Git clusters related objects (for example, multiple versions of the same file) so it can compress them effectively.

2. Delta compression: Instead of storing every version in full, Git stores one full version and then stores deltas (differences) for the others. Older versions can be reconstructed by applying deltas.

3. Compression: The packed data is compressed (zlib), just like loose objects, but now Git can often compress even better because it is working with a larger, more structured dataset.

The Impact on Repository Size

Imagine a 1MB configuration file modified 100 times.

• Without packing, Git would store many full versions (each compressed, but still substantial). You might end up with something on the order of tens of megabytes or more across history.

• With packing, Git can store one full version plus small deltas for the other 99 versions. If each change touches only a few lines, each delta could be only a few kilobytes, so the total might be closer to a couple of megabytes.

This is why repositories with years of history and thousands of commits can still clone in a reasonable size. Git is not shipping every full file version. It is shipping a compact representation built from packed objects and deltas.

When Packing Happens

You usually do not need to trigger packing manually. Git does it for you:

• git gc explicitly runs garbage collection and repacking

• git push / git fetch / git clone often involve packing or repacking for efficient transfer

• Git can also run GC automatically when loose objects grow past certain thresholds

You rarely think about pack files day to day, but they are a big reason Git scales so well and why repository sizes are manageable despite storing complete history.

Key Takeaways

Git is a content-addressable filesystem. Every piece of data is stored by its SHA-1 hash. Same content, same hash, stored once.

Three object types matter. Blobs store file contents. Trees store directory structure. Commits store snapshots with history links.

The three areas structure your workflow. Working directory for editing, staging area for drafting commits, repository for permanent storage.

Branches are just pointers. A branch is a 41-byte file containing a commit hash. Creating branches is instant. Switching branches regenerates the working directory.

Merging connects histories. Fast-forward when possible, three-way merge when branches diverge. Conflicts happen when the same lines change differently.

Pack files keep Git efficient. Delta compression and grouping allow Git to store extensive history in surprisingly little space.

Thank you for reading!

If you found it valuable, hit a like ❤️ and consider subscribing for more such content every week.

If you have any questions/suggestions, feel free to leave a comment.

But the interesting questions start after the definition:

• How does the load balancer decide which server should handle a request?

• What’s the difference between L4 and L7 Load Balancers?

• What happens when a server slows down or goes offline mid-traffic?

• How can the load balancer ensure that request from the same client always go to the same server?

• And what happens if the load balancer itself goes down?

In this article, we’ll answer these questions and build an intuitive understanding of how load balancers work in real systems.

Let’s start with the basics: why we need load balancers in the first place.

1. Why Do We Need Load Balancers?

Imagine a web app with just one server. Every user request hits the same machine.

It works… until it doesn’t. This “single-server” setup has a few fundamental problems:

1. Single Point of Failure: If the server crashes, your entire application goes down.

2. Limited Scalability: A single server can only handle so many requests before it becomes overloaded.

3. Poor Performance: As traffic increases, response times degrade for all users.

4. No Redundancy: Hardware failures, software bugs, or maintenance windows cause complete outages.

A load balancer solves these problems by distributing traffic across multiple servers.

With this setup, you get:

• High Availability: If one server fails, traffic is automatically routed to healthy servers.

• Horizontal Scalability: You can add more servers to handle increased load.

• Better Performance: Requests are distributed, so no single server is overwhelmed.

• Zero-Downtime Deployments: You can take servers out of rotation for maintenance without affecting users.

But how does the load balancer decide which server should handle each request?

2. Load Balancing Algorithms

The load balancer uses algorithms to distribute incoming requests. Each algorithm has different characteristics and is suited for different scenarios.

Below are the most common ones you’ll see in real systems.

2.1 Round Robin

The simplest algorithm. Requests are distributed to servers in sequential order.

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A  (cycle repeats)
Request 5 → Server B
...

Pros:

• Simple to implement

• Works well when all servers have equal capacity

• Predictable distribution

Cons:

• Does not account for server load or capacity differences

• A slow request on one server does not affect the distribution

Best for: Homogeneous server environments where all servers have similar specs and requests have similar processing times.

2.2 Weighted Round Robin

An extension of Round Robin where servers are assigned weights based on their capacity.

Server A (weight=3): Handles 3 out of every 6 requests
Server B (weight=2): Handles 2 out of every 6 requests
Server C (weight=1): Handles 1 out of every 6 requests

Pros:

• Still simple

• Better for mixed instance sizes (e.g., 2 vCPU + 4 vCPU + 8 vCPU)

Cons:

• Still not load-aware in real time

• If one server becomes slow (GC pause, noisy neighbor, warm cache vs cold cache), it will still get its scheduled share

Best for: Heterogeneous environments where servers have different capacities (e.g., different CPU, memory, or network bandwidth).

2.3 Least Connections

Routes requests to the server with the fewest active connections.

This algorithm is dynamic, it considers the current state of each server rather than using a fixed rotation.

Server A: 10 active connections
Server B: 5 active connections  ← Next request goes here
Server C: 8 active connections

Pros:

• Adapts to varying request processing times

• Naturally balances load when some requests take longer than others

Cons:

• Requires tracking connection counts for each server

• Slightly more overhead than Round Robin

Best for: Applications where request processing times vary significantly (e.g., database queries, file uploads).

2.4 Weighted Least Connections

Combines Least Connections with server weights. The algorithm considers both the number of active connections and the server’s capacity.

Score = Active Connections / Weight

Server A: 10 connections, weight 5 → Score = 2.0
Server B: 6 connections, weight 2  → Score = 3.0
Server C: 4 connections, weight 1  → Score = 4.0

Next request goes to Server A (lowest score)

Pros:

• Works well for mixed instance sizes and mixed request durations

• More robust than either “weighted” or “least connections” alone

Cons:

• Needs reliable tracking + weight tuning

• Still uses connections as a proxy for load (not always perfect)

Best for: Heterogeneous environments with varying request processing times.

2.5 IP Hash

The client’s IP address is hashed to determine which server handles the request. The same client IP always goes to the same server.

hash(192.168.1.10) % 3 = 1 → Server B
hash(192.168.1.20) % 3 = 0 → Server A
hash(192.168.1.30) % 3 = 2 → Server C

Pros:

• Simple session persistence without cookies

• No additional state to track

Cons:

• Uneven distribution if IP addresses are not uniformly distributed

• Server additions/removals cause redistribution of clients

Best for: Applications requiring basic session persistence without cookie support.

2.6 Least Response Time

Routes requests to the server with the fastest response time and fewest active connections.

The load balancer continuously measures:

• Average response time for each server

• Number of active connections

Pros

• Optimizes for perceived performance

• Can avoid slow/unhealthy servers before they fully fail

Cons

• Highest operational complexity (needs continuous measurement and smoothing)

• Can “overreact” to noise without careful tuning (feedback loops)

• Requires good metrics and stable observation windows

Best for: Latency-sensitive applications where response time is critical.

3. Layer 4 vs Layer 7 Load Balancing

Read more

This is the most common advice when a query runs slow. And it works. Indexes can turn a 30-second query into a 30-millisecond one.

But indexes aren’t free. Every index you create comes with costs that are easy to overlook until they become a problem.

In this article, we’ll explore the hidden costs of database indexes that every developer should understand before reaching for `CREATE INDEX`.

1. The Write Performance Penalty

When you think about indexes, you probably think about SELECT queries. But every index also affects INSERT, UPDATE, and DELETE operations.

Here’s why: an index is a separate data structure (usually a B-Tree) that maintains a sorted copy of the indexed column(s) along with pointers to the actual rows. When you modify data in the table, the database must also update every index on that table.

How Each Operation is Affected

INSERT: For every new row, the database must:

1. Write the row to the table

2. Find the correct position in each B-Tree index

3. Insert a new entry in each index

4. Potentially rebalance the B-Tree if nodes split

UPDATE: When you update an indexed column, the database must:

1. Update the row in the table

2. Remove the old entry from the index

3. Insert a new entry at the correct position

4. This is essentially a DELETE + INSERT on the index

DELETE: For every deleted row, the database must:

1. Remove the row from the table

2. Find and remove the corresponding entry in each index

3. Potentially rebalance the B-Tree

Real-World Impact

Consider a table with 5 indexes. Every INSERT now requires 6 write operations instead of 1. The overhead compounds quickly:

These numbers are approximate and depend on many factors (index type, column size, tree depth), but the trend is clear: more indexes = slower writes.

For write-heavy workloads like logging systems, event tracking, or IoT data ingestion, this overhead can become a serious bottleneck.

2. Storage Overhead

Read more

This is the most comprehensive course I’ve built, covering 55 interview problems, 20 technology deep dives, and 20 reusable patterns that appear across multiple problems.

Many chapters are free to explore. To unlock full access, you need to become a paid subscriber to the newsletter.

Check it out here

This is in addition to my System Design Fundamentals and Low-Level Design Courses. I also updated my popular system design github repository with more free resources.

What’s Inside?

55 interview problems categorized into buckets

Organized into 12 practical categories including:

• Real-Time Communication: WhatsApp, Slack, Zoom, Google Docs

• Social Media: Instagram, TikTok, Reddit, FB News Feed, Tinder

• Media Streaming: Spotify, YouTube, Netflix, Twitch, Google Drive

• Location-Based: Airbnb, Food Delivery, Uber, Google Maps

• Search & Aggregation: Autocomplete, Web Crawler, Google Search, Ad Click Aggregator

• E-commerce & Marketplace: Amazon, Shopify, Flash Sale, Movie Booking, Auction System

• Financial System: Payment Systems (Stripe), Digital Wallet, Stock Exchange

• Distributed Infrastructure: Key-Value Store, Distributed Cache, CDN, Rate Limiter, Message Queue

• Counting & Ranking: Likes Counter, Top K, Real-Time Leaderboard

• Asynchronous Systems: Notification Service, Job Scheduler, CI/CD Pipeline

20 Technical Deep Dives

Learn how popular technologies work under the hood and when to use them in interviews:

• Databases: PostgreSQL, MySQL, MongoDB, Cassandra, DynamoDB

• Caching: Redis, Memcached

• Search: Elasticsearch

• Messaging: Kafka, RabbitMQ, SQS

• Stream Processing: Flink, Spark

• Cloud & Infra: S3, Lambda, Nginx, Docker, Kubernetes

• Coordination: Zookeeper, Prometheus

20 High-Level Patterns

These patterns repeat across problems. Learn them once, apply them everywhere:

• Realtime Updates

• Fanout Pattern

• High Read/Write Traffic

• Hot Keys

• Traffic Spikes

• Handling Large Files

• Media Streaming

• Location Data

• Generating Unique IDs

• Distributed Counting

• Leader Election

• Failure Detection and Handling

• Recommendations

• Multi-Tenancy

• Multi-Region Architecture

• Deduplicating Data

• Distributed Transactions

• Removing Single Points of Failure

Interactive Simulations

There is interactive simulations for problems to help you better understand the system and functional requirements before diving into the solution.

Quizzes After Each Chapter

Every chapter ends with a quiz to test your understanding. These quizzes help reinforce the concepts and ensure you’re retaining what you learn before moving to the next topic.

Check it out here

For any questions related to content or subscription, please reply to this email or reach out at contact@algomaster.io

GitHub Copilot, Cursor, Claude, ChatGPT. Every developer has tried at least one.

And for small projects, they work great. But something breaks when you try to use these tools in a large, production codebase.

The suggestions become generic. The AI hallucinates function names that don’t exist. It confidently tells you to import a module that isn’t in your project.

This isn’t a flaw in the AI models themselves. It’s a context problem.

And understanding this problem is the key to actually getting value from AI in professional software development.

In this article, I’ll share why AI struggles with large codebases and share practical tips for using it effectively at that scale.

📣 Better Context. Better Agent. Better Code. Better Code Review.

Augment Code is an AI coding assistant built for real-world engineering teams shipping millions of lines of code.

They recently launched an industry-leading code review tool that actually understands context, not just diffs.

Instead of blindly reacting to changed lines, Augment loads the full picture – the files your PR touches, the dependencies around them, and the architecture three layers deep.

What does that look like in practice?

• Code reviews with full-codebase awareness, not just the diff you pushed.

• Inline comments, right in GitHub: no extra dashboards or tools to check.

• One-click fixes from your IDE or terminal with Augment Code

• High-signal comments developers actually read

Try Code Review

Why AI Struggles with Large Codebases

To understand why AI coding tools struggle at scale, you need to understand how they work.

When you ask an AI assistant a question about your code, it needs context. Without context, it’s just guessing based on patterns it learned during training.

Here’s the problem: most AI tools have a very limited view of your codebase.

What AI sees:

What it needs to see:

The Context Window Problem

Every LLM has a context window, the maximum amount of text it can consider at once. Even with context windows of 100K+ tokens, you can’t just dump your entire codebase into a prompt.

A typical production codebase might have:

• 10,000+ source files

• 1 million+ lines of code

• Hundreds of internal APIs

• Years of accumulated conventions and patterns

You can’t fit that into any context window. So AI tools have to be selective about what they include.

Most tools solve this by looking at:

• The file you’re currently editing

• Maybe a few open tabs

• Sometimes files you’ve recently viewed

That’s it. The AI has no idea about your authentication service three directories over, the utility functions your team uses constantly, or the database schema that defines your data model.

The Stale Context Problem

Here’s another issue that gets overlooked: your codebase changes constantly.

You switch branches multiple times a day. Your teammates merge PRs. You run search-and-replace across dozens of files. The code that existed five minutes ago might not exist now.

Most AI indexing systems update on a schedule, often every 10 minutes or longer. In that time, you might have:

• Switched to a feature branch

• Renamed a key function

• Added new type definitions

• Merged in your colleague’s changes

If the AI’s understanding of your codebase is 10 minutes old, it’s working with outdated information. It might suggest importing a module that was just renamed, or recommend a function signature that no longer exists.

This is especially painful when you’re doing code review. You check out a PR branch, ask the AI about the changes, and it responds based on the main branch because its index hasn’t caught up yet.

The Retrieval Problem (And Why It Matters)

At its core, making AI useful in large codebases is a retrieval problem.

The AI model itself is powerful. GPT-4, Claude, and others can understand and generate code remarkably well. The bottleneck is getting the right context into the model’s prompt before it generates a response.

This is conceptually similar to RAG (Retrieval Augmented Generation) for documents, but with code-specific challenges:

Code relationships are complex

Unlike documents, code has rich structural relationships. A function definition isn’t just similar to its call sites textually, it’s semantically connected. Documentation isn’t necessarily similar to the code it describes.

Generic embedding models trained on text don’t capture these relationships well.

Context relevance isn’t just about similarity

When you’re writing code, the most “relevant” context isn’t always the most similar text. If you’re implementing a new API endpoint, you probably need:

• Similar endpoints for pattern matching

• The authentication middleware

• Data validation utilities

• Database query helpers

• Error handling conventions

These aren’t necessarily textually similar to what you’re writing, but they’re essential context.

Some “relevant” context is actually useless

Here’s a counterintuitive point: sometimes the most semantically similar code is the least helpful.

If you’re using PyTorch and the AI retrieves PyTorch source code, that’s probably not useful. The model already knows how PyTorch works. It was trained on that. What it doesn’t know is your specific project structure, your team’s conventions, your custom utilities.

The ideal retrieval system prioritizes helpfulness over raw relevance.

What Actually Works

After years of trying to make AI useful in professional development, here’s what I’ve learned actually matters:

1. Deep Codebase Indexing

The AI needs to understand your entire codebase, not just open files.

This means:

• Indexing all source files, not just recent ones

• Understanding relationships between files (imports, dependencies, call graphs)

• Capturing type definitions, interfaces, and schemas

• Learning your project structure and conventions

The index also needs to stay current. If you switch branches, the AI should immediately understand the new state of the code. If you rename a function, it should know about that within seconds, not minutes.

2. Context-Aware Retrieval

When you ask a question or request a code change, the AI needs to pull in relevant context intelligently.

Good retrieval considers:

• Direct relationships: What files import this one? What does this file import?

• Semantic relationships: What other code does similar things?

• Structural context: What’s the project structure around this file?

• Historical patterns: How has your team solved similar problems before?

3. Branch-Aware Understanding

Your AI assistant needs to understand that you work on branches.

When you switch from main to feature/new-auth, everything changes. The AI should:

• Immediately understand the new branch state

• Not mix up code from different branches

• Handle rebases and merges gracefully

• Provide suggestions based on the current branch, not a stale main

4. Security-Conscious Architecture

For production codebases, security isn’t optional.

The AI system should:

• Respect access controls (don’t retrieve code the user can’t access)

• Not send sensitive code to third-party APIs unnecessarily

• Maintain audit trails of what was accessed

• Comply with your organization’s security requirements

How Augment Code Approaches This

This is where I want to talk about Augment Code, our sponsor for this post.

I’ve been using Augment for the past few weeks, and it solves many of the problems I described above in ways that other tools don’t.

Real-Time Indexing

Augment maintains a personal search index for each developer that updates within seconds of code changes.

When you switch branches in git, when you do a search-and-replace across 100 files, when your colleague’s PR gets merged, Augment’s index reflects those changes almost immediately.

I tested it.

I downloaded the Kafka source code from GitHub (around 7,000 files, 300+ MB). Augment indexed it in under a minute. I asked questions about Kafka’s internals, like “show me the code path for storing messages to log files”, and it found the relevant code paths accurately.

On my own project (1,000+ files), the index updated in about 10 seconds.

Custom Embedding Models

Augment doesn’t use generic embedding models like most tools.

They’ve trained custom models specifically for code retrieval. These models understand that:

• A function call site is related to its definition (even though they look different)

• Documentation is related to the code it describes

• Code in different languages can be semantically related

• Common library code (like PyTorch internals) doesn’t need to be retrieved since the model already knows it

This matters because generic embeddings optimized for text similarity often miss the connections that matter in code.

The Prompt Enhancer

This is something Augment users consistently mention as their favorite feature.

You don’t have to be a prompt engineer to get good results. The system takes your simple request and automatically enriches it with relevant context from your codebase.

I tested this on my website project. I gave it a minimal prompt: “Update comment component to allow users to edit their comments.”

No additional context. No file paths. No architecture explanation.

Augment built the complete feature in one prompt: UI components, database calls, edge case handling, everything. It understood my project’s patterns, my component structure, my database schema, and generated code that fit naturally.

That’s what good retrieval enables. The model has all the context it needs to make intelligent decisions.

Security By Design

Augment self-hosts their embedding search and doesn’t use third-party APIs for retrieval. This matters because research has shown that embeddings can be reverse-engineered back to source code.

They also implement proof-of-possession for file access. The IDE has to prove it knows a file’s content before the backend will return information about that file. This prevents retrieving code you’re not authorized to access.

Practical Tips for Using AI in Large Codebases

Whether you’re using Augment or another tool, here are strategies that help:

1. Provide Explicit Context

Don’t assume the AI knows your codebase structure.

Instead of:

Fix the bug in the user service

Try:

In src/services/user/authentication.ts, the validateToken
function is not checking token expiration correctly.
It should use the exp claim from the JWT payload.

Explicit file paths and specific details help the AI focus on the right area.

2. Reference Related Files

If you know what files are relevant, mention them.

Update the UserProfile component (src/components/UserProfile.tsx)
to display the user’s subscription status.

The subscription data comes from the useSubscription hook
(src/hooks/useSubscription.ts) and follows the same pattern
as the useAccount hook.

3. Explain Your Conventions

AI tools don’t automatically know your team’s patterns.

Create a new API endpoint for updating user preferences.

Follow the same pattern as the existing endpoints in
src/api/routes/:
- Use the validateRequest middleware
- Return responses using the ApiResponse wrapper
- Log errors to the auditLogger

4. Work Iteratively

Don’t expect perfect results on the first try.

Start with a simple request, review what the AI generates, and provide corrections. Each iteration helps narrow in on what you actually need.

5. Use AI for Exploration

Large codebases are hard to navigate. AI tools excel at questions like:

• “How does authentication work in this codebase?”

• “What’s the flow when a user places an order?”

• “Where is the database connection configured?”

These exploration queries help you get oriented quickly, even in unfamiliar code.

The Future of AI in Professional Development

The tools we have today are just the beginning.

As retrieval systems get better, as context windows expand, and as models become more capable, AI assistants will become genuinely useful for complex professional work.

The key insight is that model capability isn’t the bottleneck anymore. Context is. The teams building the best code understanding, the best retrieval systems, and the best context management will build the most useful tools.

This is why I’m excited about tools like Augment that focus specifically on professional development in large codebases. They’re solving the hard problems that make AI actually useful, not just impressive in demos.

Try Augment Code

If you work with large codebases and want to see what proper context awareness looks like, try Augment Code.

They have:

• VS Code and JetBrains extensions

• A CLI tool for terminal users

• SOC 2 Type II compliance for enterprise requirements

• A free trial to test it on your own codebase

• A newly launched industry leading code review tool

The best way to evaluate any AI tool is to try it on your actual work. See if it understands your codebase, your conventions, your patterns.

Although they are used interchangeably sometimes, they’re not the same thing.

Simply put:

A message broker is the infrastructure. Message queues and pub-sub are messaging patterns that brokers implement.

In this article, we’ll explore:

• What each term means

• How they differ architecturally

• When to use each pattern

• Real-world examples and use cases

• How modern systems like Kafka, RabbitMQ, and Redis fit in

1. The Core Concepts

Before diving into comparisons, let’s define each term clearly.

1.1 Message Broker

A message broker is the middleware infrastructure that receives, stores, and routes messages between producers and consumers. It’s the “thing” that sits in the middle.

Think of a message broker like a post office. It receives mail (messages), stores it temporarily, and delivers it to the right recipients based on addresses (routing rules).

Examples: RabbitMQ, Apache Kafka, ActiveMQ

Key responsibilities:

• Accept messages from producers

• Store messages durably or transiently

• Route messages to appropriate consumers

• Handle delivery guarantees (at-least-once, exactly-once)

• Manage consumer acknowledgments

1.2 Message Queue

A message queue is a messaging pattern where messages are sent to a queue and consumed by exactly one consumer. Messages are typically processed in order and removed from the queue after consumption.

Message queues enable asynchronous service-to-service communication, especially in serverless and microservices architectures. They allow you to build reliable background processing, work distribution, and decoupled systems.

Examples: SQS queues, RabbitMQ queues

When multiple consumers connect to the same queue, they compete for messages. Each message goes to exactly one consumer.

Key Characteristics:

• Delivery: Exactly one consumer receives each message

• Ordering: First-In-First-Out (FIFO) ordering within a single queue

• Persistence: Messages stored until consumed and acknowledged

• Acknowledgment: Consumer must confirm successful processing

• Retry: Failed messages can be retried or dead-lettered

1.3 Pub-Sub (Publish-Subscribe)

Pub-Sub is a messaging pattern where publishers send messages to topics, and all subscribers to that topic receive a copy of the message. Messages are broadcast, not consumed exclusively.

Think of it like a radio broadcast. The station (publisher) broadcasts a signal (message), and everyone tuned to that frequency (subscribers) receives it simultaneously.

It’s an asynchronous communication model that decouples services, making it easier to build scalable, event-driven systems. Pub/Sub is widely used in modern cloud architectures to deliver instant event notifications and enable reliable communication between independent components.

Examples: Redis Pub/Sub, SNS

Pub-sub naturally implements fan-out in event-drive architectures, where one event triggers multiple actions:

Key Characteristics:

• Delivery: One-to-many. Each message delivered to all subscribers.

• Decoupling: Publishers and subscribers are decoupled

• Scalability: Easy to add new subscribers

• Persistence: Messages may or may not be removed after delivery (depends on implementation)

2. How Brokers Implement Both

Read more

You want to build something scalable from day one.

So you begin designing your system with separate services for users, orders, payments, notifications, and inventory. Each with its own database, its own deployment pipeline, its own monitoring setup.

Six months later, you have 15 services, a team of 3 developers, and you’re spending 80% of your time debugging distributed system issues instead of building features.

This is the microservices trap, and it catches more teams than you might think.

In this article, I’ll explain:

• Why microservices are exciting but dangerous for new projects

• The hidden costs that nobody talks about

• When microservices actually make sense

• The “Monolith First” approach and why it works

• Why microservices are important in System Design Interviews

The Microservices Hype

Microservices sound exciting and they always look impressive in system design interviews.

The idea of having small, independent services that can be developed, deployed, and scaled independently sounds like engineering nirvana.

When you read about microservices, you hear about:

• Independent deployments: Deploy one service without affecting others

• Technology flexibility: Use the best language/framework for each service

• Team autonomy: Small teams own their services end-to-end

• Scalability: Scale only the services that need it

• Fault isolation: One service failure doesn’t bring down the system

These benefits are real. But they come with a catch.

These benefits only materialize at scale, both in terms of traffic AND team size.

For a startup or small team, microservices don’t just fail to provide these benefits. They actively work against you.

Let me show you why.

The Hidden Costs of Microservices

1. Distributed Systems Complexity

The moment you split your application into multiple services, you’ve created a distributed system. And distributed systems are hard.

Problems that didn’t exist in a monolith suddenly become your daily reality:

• Network failures - Service A can’t reach Service B. Now what?

• Latency - A function call that took microseconds is now a network call taking milliseconds

• Data consistency - How do you maintain consistency across multiple databases?

• Debugging nightmares - A single request might touch 10 services. Good luck tracing that error.

In a monolith, calling a function is guaranteed to either work or throw an exception.

In microservices, a service call can:

• Succeed

• Fail with an error

• Timeout (but did it actually succeed?)

• Succeed but return stale data

• Succeed on retry but cause duplicate operations

Each of these scenarios requires different handling. Multiply this by every service-to-service call in your system.

What about debugging?

In a monolith you get a stack trace.

In a microservices architecture, a single user request might touch 10 different services. When something goes wrong, you need to trace through logs across all of them, correlate timestamps, and figure out which service caused the failure.

But distributed complexity is just the beginning. How do you even manage all these services?

2. Operational Overhead

A monolith means one thing to deploy, monitor, and maintain.

With microservices, everything multiplies:

You’ll also need additional infrastructure that a monolith simply doesn’t require:

• Service discovery: How do services find each other?

• API Gateway: How do external clients reach your services?

• Distributed tracing: How do you debug across services?

• Circuit breakers: How do you handle cascading failures?

• Message queues: How do services communicate asynchronously?

Each of these adds complexity, cost, and potential failure points. A small team can easily spend more time managing infrastructure than building features.

Speaking of performance costs, let’s look at what happens to your application’s speed.

3. Network Is Now Your Bottleneck

In a monolith, data access is fast (~1 microsecond). Objects are in memory or a single database call away.

In microservices, what was once a method call is now:

1. Serialize request to JSON           ~0.5ms
2. DNS lookup                          ~1-10ms
3. TCP connection                      ~1-5ms
4. TLS handshake                       ~5-30ms
5. Send HTTP request                   ~1-5ms
6. Service B processes                 ~varies
7. Serialize response                  ~0.5ms
8. Network transfer back               ~1-5ms
9. Deserialize response                ~0.5ms

Time: 10-50+ milliseconds (10,000x slower!)       

This overhead adds up quickly. A page that required 5 internal method calls in a monolith might now require 5 network calls, each adding 10-50ms of latency.

4. Data Management Becomes a Nightmare

One of the “benefits” of microservices is that each service owns its data. But this creates serious challenges.

The Join Problem

In a monolith, you can easily join users with orders with products in a single SQL query:

SELECT u.name, o.total, p.title
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id
WHERE u.id = 123;

In microservices, the same data lives in different databases:

To get user + orders + products, you need to:

1. Call the Users service

2. Call the Orders service

3. Call the Products service

4. Join the data in your application code

The Transaction Problem

In a monolith, you can wrap multiple operations in a database transaction:

In microservices, each service has its own database. You can’t have a transaction span multiple services. Instead, you need distributed transactions or saga pattern - both are complex and error-prone.

5. Testing Is Exponentially Harder

Testing a monolith is straightforward: spin up the application, run your tests.

Testing microservices requires multiple layers:

• Contract testing between services

• Integration tests that spin up multiple services

• End-to-end tests across the entire system

• Chaos engineering to verify fault tolerance

Your CI/CD pipeline becomes a complex orchestration of building, deploying, and testing multiple services in the correct order. A change to a shared API requires updating and testing all dependent services.

6. You Don’t Know Your Domain Yet

This might be the most important point.

When you’re starting a new project, you don’t fully understand your domain.

Requirements will change. You’ll discover that what you thought were separate concerns are actually deeply intertwined.

In a monolith, refactoring is moving code between packages. In microservices, refactoring is redesigning APIs, migrating data, and coordinating deployments across teams.

Martin Fowler calls this the Monolith First approach:

“Almost all the successful microservice stories have started with a monolith that got too big and was broken up.”

— Martin Fowler

Starting with microservices means you’re drawing service boundaries before you understand where they should be. And wrong boundaries are incredibly expensive to fix.

So when do microservices actually make sense?

When Microservices Actually Make Sense

Read more