That is where messaging systems come in. They sit between producers and consumers, buffer work, decouple services, and let each side scale independently.

But choosing a messaging system is not always obvious. Kafka, RabbitMQ, and Amazon SQS are populars solutions, but they are built for different kinds of workloads.

In this article, we’ll compare Kafka, RabbitMQ, and SQS across the key dimensions that matter when designing asynchronous systems, and explain when to choose each one.

📣 Research Agents That Find, Verify, and Explain (Sponsor)

Deep research agents should do more than find answers. They should show why those answers can be trusted.

Apodex is built for long-horizon research tasks where reliability matters. It plans the search, gathers evidence, uses tools, verifies findings, and synthesizes grounded responses.

Its verification-first design separates the solver from the verifier, using different context and tools to reduce unsupported conclusions.

Apodex recently launched Apodex 1.0, a deep research agent family built around independent verification.

This release includes:

• Apodex-1.0-H, our flagship deep research model

• AgentOS, a runtime for building and evaluating agent workflows

• Apodex-1.0 and Apodex-mini

• Open-weight Smol models at 0.8B, 2B, and 4B

Apodex is now available for researchers, scientists, developers, and builders worldwide.

• Github: https://github.com/ApodexAI/AgentHarness

• Hugging Face: https://huggingface.co/collections/apodex/apodex-1

• Try Apodex (early access): https://www.apodex.ai

• API Platform: https://platform.apodex.ai/

• Join Discord: https://discord.gg/TDJA59TCng

1. Three Different Models

Before comparing them, it helps to understand what each system fundamentally is. Most confusion comes from treating Kafka, RabbitMQ, and SQS as interchangeable queues. They are not.

Here’s the core model behind each one.

Kafka stores messages in an append-only log. Consumers track their position with offsets, and messages remain available until the retention period expires. This allows multiple consumers to read the same data independently and replay old messages when needed.

RabbitMQ works more like a traditional broker. Producers send messages to exchanges, exchanges route them to queues, and consumers receive messages from those queues. Once a consumer acknowledges a message, RabbitMQ removes it.

SQS is simpler. You send messages to a queue, consumers poll the queue, and AWS manages the infrastructure behind it.

The table below summarizes how they differ across different dimensions:

Share

2. Apache Kafka: The Distributed Log

Kafka was originally built at LinkedIn to move large volumes of activity data, such as page views, clicks, and searches, across many internal systems. Traditional message brokers were not a great fit for that scale, so Kafka took a different approach: it modeled messaging as a distributed append-only log.

The core idea is simple. Messages are appended to ordered, immutable logs. Each topic is split into partitions, and those partitions are spread across brokers for parallelism and fault tolerance.

Producers write messages to a topic. A partition key decides which partition a message lands in, so related messages can stay ordered within the same partition.

Consumers read messages by offset. Kafka does not delete a message when it is read. Instead, messages stay in the log until the retention period expires. This is what makes replay possible.

Consumer groups are the main scaling mechanism. Within one consumer group, each partition is assigned to only one consumer. You can increase parallelism by adding more partitions and consumers.

If another consumer group reads the same topic, it gets its own independent view of the stream. That means the same event feed can power analytics, billing, search indexing, fraud detection, and other systems at the same time.

Kafka is fast because it is built around sequential I/O. Writes are appended to disk, reads are served efficiently from the operating system page cache, and messages are batched and compressed. This lets Kafka handle very high throughput across a cluster.

Strengths

• Very high throughput on commodity hardware

• Messages are retained, so consumers can replay history

• Multiple independent consumer groups read the same data

• A mature stream-processing ecosystem (Kafka Streams, ksqlDB, Connect)

Weaknesses

• Operationally heavy to run yourself (brokers, partitions, rebalancing, and historically ZooKeeper, now KRaft)

• No per-message routing logic; consumers filter on their own

• No native priority queues or per-message delay

• Overkill for simple task queues

Choose Kafka when you need replay, event sourcing, very high throughput, real-time stream processing, or multiple teams consuming the same event feed independently. Kafka is best when events become a long-lived stream of data, not just temporary work items.

3. RabbitMQ: The Flexible Broker

RabbitMQ is a traditional message broker built around routing and reliable delivery. While Kafka is optimized for storing and replaying large event streams, RabbitMQ is optimized for getting each message to the right consumer quickly.

The key idea is that producers do not usually publish directly to queues. They publish to an exchange. The exchange then routes each message to one or more queues using rules called bindings.

RabbitMQ supports several exchange types:

• Direct: Routes by exact routing key match

• Topic: Routes by pattern, such as order.*

• Fanout: Broadcasts to all bound queues

• Headers: Routes based on message headers

This routing model is RabbitMQ’s biggest strength. It lets you express routing rules in the broker instead of hardcoding them in every producer or consumer.

RabbitMQ delivery is push-based. The broker sends messages to consumers, and each consumer acknowledges a message after processing it. Once RabbitMQ receives the acknowledgment, it removes the message from the queue. If the consumer crashes before acknowledging, the message can be requeued and delivered again.

This push-and-ack model makes RabbitMQ a good fit for low-latency task processing, background jobs, and workflows where each message needs to reach a specific worker.

Strengths

• Flexible routing through exchange types

• Low per-message latency from push-based delivery

• Native support for priority queues, per-message TTL, and delayed delivery (via plugin)

• Multiple protocols (AMQP, MQTT, STOMP) and a built-in management UI

Weaknesses

• Lower throughput than Kafka, typically tens of thousands of messages per second per node

• No replay; once a message is acked, it’s gone

• Throughput drops when queues grow very deep, since it’s tuned for queues that stay near empty

• Clustering and mirrored/quorum queues add operational complexity

Choose RabbitMQ when you need flexible routing, priority queues, request-reply patterns, per-message delays, or low latency for individual messages. It is a strong fit when the main problem is getting each message to the right worker quickly and reliably.

Kafka and RabbitMQ both require you to think about brokers, capacity, scaling, and operations. SQS takes a different approach by making the queue fully managed.

4. Amazon SQS: The Managed Queue

Amazon SQS is the simplest of the three. It gives up Kafka’s replay model and RabbitMQ’s rich routing in exchange for one major benefit: almost no operational work.

There are no brokers to provision, no clusters to size, and no replication settings to manage. You create a queue, send messages to it, and AWS handles the infrastructure behind it.

The flow is straightforward. Producers send messages to a queue. Consumers poll the queue for messages. AWS manages durability, scaling, and availability.

The important concept is the visibility timeout. When a consumer receives a message, SQS does not delete it immediately. Instead, it hides the message from other consumers for a configured period. The consumer processes the message and then explicitly deletes it.

If the consumer crashes before deleting the message, the visibility timeout expires and the message becomes available again. Another consumer can then pick it up. After a configured number of failed attempts, the message can be moved to a dead-letter queue for later inspection.

SQS has two main queue types:

• Standard queue: Very high throughput, at-least-once delivery, best-effort ordering

• FIFO queue: Preserves order within a message group and supports deduplication, but with lower throughput

Strengths

• No infrastructure to manage (AWS manages it for you)

• Scales automatically and absorbs traffic spikes

• Deep AWS integration (Works well with Lambda, SNS, S3, CloudWatch, and other services)

• Pay-per-request pricing with no idle cost

Weaknesses

• AWS-only; no portability to other clouds or on-premise

• No replay and 14-day maximum retention

• No built-in routing (you pair it with SNS for fan-out)

• 256 KB message size limit, and FIFO throughput is capped

Choose SQS when you are building on AWS and want a reliable queue with almost no operational overhead. It is ideal for serverless workflows, bursty background jobs, and simple asynchronous processing where you do not need replay or advanced routing.

5. Using Them Together

Kafka, RabbitMQ, and SQS are not mutually exclusive. Mature systems often use more than one because they solve different problems.

A common pattern is to use Kafka as the central event backbone. Services publish high-volume events to Kafka, and downstream systems consume those events for analytics, stream processing, search indexing, billing, or auditing.

From there, a bridge service can forward selected events to a task queue. Use RabbitMQ when the work needs flexible routing, priority handling, or dedicated worker pools. Use SQS when the work is AWS-native and you want services like Lambda, ECS, or EC2 workers to process it with minimal operations.

This split plays to each system’s strengths. Kafka handles durable, replayable, high-throughput event streams. RabbitMQ and SQS handle short-lived task processing, where messages represent work that disappears once completed.

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

Excited to share that we now have 1000+ animations live on AlgoMaster.io covering DSA, System Design, AI/ML, SQL and more.

These animations are designed to help you understand concepts quickly with clear and intuitive visuals instead of just reading theory, memorizing steps or watching an hour long video.

You can browse the full list here. Many of these animations are free to explore. For full access, you can subscribe to premium.

I’ve also started sharing animated videos on instagram, and it just crossed 100k+ followers in 2 months. You can follow here to stay updated.

The animations are also integrated directly into AlgoMaster.io courses, so you can learn a concept and visualize it at the same time.

Whether you are preparing for coding interviews, system design interviews, or trying to to get good at AI/ML, these should make the learning process much smoother.

I’ll keep adding more useful animations and improving the existing ones over time.

Hope you find them useful.

P.S. I’ve also started adding video content on the platform and plan to cover most of the important topics over the coming months.

LLM training occurs in stages, with each step guiding the model to become more useful than the previous one. These stages are as follows:

1. Pretraining

2. Mid-training

3. Post-training

In general, each subsequent stage of training requires:

• Less training data

• Cleaner and more domain-specific datasets

• More sophisticated algorithms

Let’s learn about each stage in more depth in the subsequent sections.

Pretraining

Pretraining is the first stage in LLM training that teaches it the basics of language (grammar, syntax, and semantic structure) and gives it foundational knowledge of the world.

Large datasets containing trillions of tokens of information scraped from the web are used for LLM pretraining. Some of these datasets are:

• Common Crawl: A massive raw dataset obtained by scraping the web. Most other pretraining datasets are filtered down from it.

• RefinedWeb: A cleaned dataset derived from Common Crawl, used to train Falcon models

• C4 (Colossal Clean Crawled Corpus): A cleaned dataset derived from Common Crawl, introduced with Google’s T5 model

• FineWeb: A cleaned dataset derived from Common Crawl with 15-trillion tokens, released by Hugging Face

• The Pile: A dataset consisting of 22 smaller, high-quality datasets combined together, released by EleutherAI

• Dolma: Dataset of more than 3 trillion tokens from AllenAI, used to train their Olmo models

An LLM is trained using the next-token prediction objective by minimizing the cross-entropy loss between the ground truth and predicted tokens at this stage. This is the most compute-intensive stage of the whole LLM training pipeline.

The resulting pretrained model is called the “Base model”, and it can generate subsequent tokens for a given prompt (not necessarily helpful ones).

At this point, it would be very helpful to learn how a pretraining dataset is created from larger unfiltered datasets such as Common Crawl. Let’s look into how Dolma 3 Mix, the pretraining dataset used to train the Olmo 3 family of models, was created. This dataset contains approximately 6 trillion tokens!

Starting from raw web archives of Common Crawl, clean text is first extracted from them, and a technique called ‘Heuristic filtering’ is then applied, which involves:

• Using URL filtering to remove spam and adult content

• Applying length filters to remove documents that are either too short or too long

• Filtering and removing documents that contain lots of symbols or insufficient quantities of alphabetic characters

• Filtering and removing documents with a large amount of repetitive content inside them

• Filtering and removing documents that contain Personally Identifiable Information (PII)

• Filtering and removing documents that are in a language other than English

• Applying sentence-level filters to find low-quality samples

The resulting documents then go through a stage of Deduplication. This is when documents are compared and copies that appear multiple times in the dataset are removed.

The deduplicated dataset is then further classified by topic and text quality and combined with other cleaned datasets from ArXiv, Wikipedia, GitHub repositories, and more.

The right mix of datasets is not guessed. Instead, small proxy models are trained on different dataset combinations, and evaluations determine which combination results in the best pretraining performance. The best-performing data is duplicated, while the lower-performing data is discarded. This step is called Quality-aware upsampling.

The resulting data mix is then used in the full pretraining.

Share

Mid-training

Mid-training is the stage in which an LLM is trained on high-quality, domain-specific data to improve its capabilities. This data focuses on:

• Very high-quality web text

• Domains like health, law, math, code, and general knowledge

• Improving reasoning (training with reasoning traces)

• Improving instruction following (training with instruction data)

• Extending context length

• Adding a new language

Alongside these, Anthropic recently introduced Model Spec Midtraining (MSM). This involves training an LLM on synthetic documents that explain its Model Spec or Constitution. A Model Spec is a document that describes how an LLM should behave, including the rules it must follow and its core values and priorities.

Experiments show that a model that has undergone MSM generalizes better and is less prone to misalignment when further alignment-tuned. We will learn more about alignment tuning in the next section of this lesson.

Some examples of mid-training datasets are:

• Dolmino Mix

• MegaMath-Web-Pro-Max

• Longmino Mix

A mid-trained model, just like the pretrained model, can generate subsequent tokens for a given prompt, but not necessarily helpful ones.

If you’re interested in learning more about the mid-training of language models, you can read a survey that discusses it in depth using this link.

Post-training

Post-training is the final phase that teaches a model to become a useful and human-value-aligned assistant, rather than one that just produces the next token.

Three post-training techniques that are popularly used are:

• Supervised fine-tuning (SFT)

• Alignment tuning/ fine-tuning

• Reinforcement learning for reasoning

Let’s discuss these in more depth.

Supervised fine-tuning (SFT)

This involves training the model on datasets consisting of prompt/instruction-response pairs (instruction data). This teaches a model how to follow instructions and produce desired responses.

Some examples of SFT datasets are:

• Alpaca

• Dolci-Think-SFT

• MathInstruct

An example of a prompt-response pair is shown below.

SFT uses next-token prediction with a cross-entropy loss over the target tokens, similar to Pretraining. The main difference is that the loss is calculated only for the response tokens, not the prompt (instruction + input).

The resulting model after SFT is called the “Instruct model” (with the suffix “-Instruct” or “-it”).

This model can generate responses to a given instruction in the prompt, but these responses might not align with human values.

Previous studies have shown that excessive SFT is harmful because it can cause the model to memorize the training data too well and struggle to generalize to out-of-distribution scenarios. This means that SFT-trained models may perform well in domain-specific tasks but tend to lose their general capabilities.

Also, SFT-trained models can lose their capability to explore and further improve with subsequent RL training. This is the reason why newer techniques like Proximal SFT are being developed.

Alignment (Fine-)Tuning

This involves training the model on preference datasets to produce helpful, honest, and safe responses aligned with human values and preferences. This step is also sometimes called Preference (Fine-) Tuning.

Each sample in a preference dataset is a prompt plus a better/preferred and a worse/rejected/non-preferred response. An example is shown below.

Alignment tuning for LLMs was popularised by OpenAI with the model ‘InstructGPT’. This was a GPT-3 model that was first fine-tuned using supervised learning and then aligned using a technique called Reinforcement Learning from Human Feedback (RLHF).

Here is how RLHF works:

1. The process of RLHF starts with an LLM that has been fine-tuned with supervised learning (SFT) to generate responses to user queries in a conversational style.

2. Multiple responses to different prompts are collected, and a human labels them from most preferred to least preferred.

3. Based on this preference data, a separate reward model (LLM) is trained to predict which response humans would prefer for a given prompt. This reward model assigns higher rewards to preferred responses and vice versa, functioning as a proxy for a human judge.

4. The LLM in training (called Policy) generates a response for a given prompt.

5. This response is evaluated by the reward model, which returns a reward.

6. Based on the reward, an algorithm called Proximal Policy Optimization (PPO) is used to update the LLM in training to produce higher-rewarded responses.

The process of RLHF with PPO is computationally and memory-intensive and hard to set up and orchestrate. This is because it uses 4 different LLMs (Policy, Reference, Reward, Value) working together.

Instead of RLHF with PPO, Alignment tuning today is commonly performed using another technique called Direct Preference Optimization (DPO). Here, we remove the RL component of RLHF and instead train the LLM directly on response-preference-pairs using a supervised objective.

Some examples of datasets used for Alignment tuning are:

• HH-RLHF

• UltraFeedback

• Dolci-Think-DPO-7B

An aligned model can generate helpful, harmless outputs that align with human values and preferences in response to a given instruction in the prompt.

Reinforcement learning for reasoning

This involves using Reinforcement learning (RL) to train a model to think and reason before responding, especially for difficult questions.

A technique called Reinforcement Learning with Verifiable Rewards (RLVR), introduced in the Tulu 3 paper, is a method for training an LLM to reason, particularly for tasks whose results can be objectively verified. This includes tasks such as math, logic and coding, where a simpler rule-based verifier (not an LLM) can check whether the answer is correct.

Compare this to alignment tuning with RLHF, which uses a reward model (an LLM) to score the responses, because the correct results are highly subjective. Tasks like this cannot be handled by RLVR.

This is how RLVR works:

1. For a given prompt to solve a math or coding task, the LLM in training (called Policy) generates response(s) to it.

2. A rule-based verifier checks whether the answer is correct or incorrect. The correct response(s) receive a reward of 1, while the incorrect ones receive 0.

3. RL algorithms such as either PPO or GRPO are used to update the Policy model and make the correct reasoning paths more likely.

This is not the only way to train a reasoning model. A reward model or an LLM judge is used instead of a programmatic verifier to train a reasoning model in domains where answers can’t be automatically verified (such as open-ended dialogue, creative writing, legal analysis, or medical diagnosis).

Alongside this, a Process Reward Model can also be used in the RL training process to grade all intermediate reasoning steps in an LLM’s reasoning chain, rather than just rewarding the final answer. This trains and prevents an LLM from getting the answer right but for the wrong reasons.

The resulting reasoning model, developed using the above techniques, is called the “Think model”.

Many LLMs are also trained using RL to reason directly from the pretrained / base model with no SFT. These models are named with the suffix “-Zero”. Some notable examples of such models include DeepSeek-R1-Zero and Olmo 3 RL-Zero.

These models have surprisingly high performance on tough benchmarks. For example, DeepSeek-R1-Zero has an average pass@1 score of 77.9% on AIME 2024 while the base model scores merely 15.6%.

Further user-specific training

Once a model has been post-trained and released, users can further train it on their own data to make it stronger in specific domains (such as law, medicine, finance, and banking) or adapt it to their use case (such as customer support requests).

This is done by training the model on prompt-response pairs from a custom dataset using:

• Full Supervised fine-tuning (SFT), where all model parameters are updated using the supervised next-token objective. Although most effective, this is highly memory and compute-intensive.

• LoRA (Low-Rank Adaptation) fine-tuning, which is a parameter-efficient version of SFT, where instead of updating every parameter, the original model is frozen, small low-rank matrices are injected into it, and only these are trained. This reduces the memory and compute needed in the fine-tuning process.

• A quantized variant of LoRA called QLoRA, which further reduces memory cost.

Note that users could even use DPO, RLVR, or other RL algorithms to further tune the model for their use case, based on the compute available to them.

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.

This post is public so feel free to share it.

Share

After conducting close to 200 interviews at Amazon, across entry-level to senior-level roles and job families such as SDE, TPM, MLE, Product Manager, and SDM, I have gained a deeper appreciation for what it means to sit on the other side of the table.

As an interviewer, my goal is not just to ask questions or judge answers. It is to objectively collect data points, identify strengths, notice potential red flags, and assess whether a candidate demonstrates the skills and behaviors expected for the role.

The Interviewer’s Responsibility

The interview process at large tech companies like Amazon is highly structured and well defined. My responsibility as an interviewer is to drive the conversation, manage time effectively, and collect enough meaningful data points to make a fair assessment.

One of the most important skills is taking detailed notes while actively listening, so that no critical signal is missed. Every follow-up question is intentional. It helps uncover more depth, clarify ambiguities, and evaluate the candidate against the expectations of the role.

A good interviewer also tries to make the candidate feel comfortable. The best interviews do not feel like an interrogation. They feel like a thoughtful discussion between peers working through a problem together.

How Candidates Are Evaluated?

As interviewers, we are assigned well-defined competencies to evaluate candidates against. These may include technical questions, role-specific expectations, and behavioral aspects such as Leadership Principles.

The evaluation criteria help us identify both strengths and areas of concern in a candidate’s performance.

A candidate is not evaluated only on whether they arrive at the correct answer. We also look at the overall signal across multiple dimensions, such as technical depth, problem-solving approach, communication clarity, ownership and accountability, ability to handle ambiguity, seniority signals, and behavioral competencies.

At Amazon, Leadership Principles are especially important and are given equal weight alongside technical performance. Strong candidates demonstrate not only that they can solve problems, but also that they can take ownership, make sound decisions, communicate effectively, and operate at the expected level for the role.

Consistency across rounds matters too. Hiring decisions are based on the overall pattern of data points collected throughout the loop, not on a single strong or weak moment in one interview.

Share

What Makes a Candidate Stand Out?

One thing that immediately stands out to me is how a candidate approaches ambiguity. Jumping straight to a solution without first clarifying the requirements is often a red flag, because it can make the interview feel mechanically rehearsed rather than thoughtful.

On the other hand, a candidate who asks relevant clarifying questions early in the discussion creates a strong first impression. It shows that they are not just trying to solve a memorized problem, but are genuinely trying to understand the problem space.

Another important signal is the ability to explain the chosen approach clearly. A strong candidate should be able to walk the interviewer through their thought process, justify why they picked a particular solution, and discuss the tradeoffs involved. The final answer matters, but the reasoning behind it often matters even more.

The candidates who handle this well tend to move through the problem in a predictable, deliberate way:

As an interviewer, I also value originality. Since I am investing my time in the conversation as well, it is always exciting when I learn something new from a candidate. There have been interviews where a candidate came up with a unique or elegant approach that I had not considered before, and that immediately left a strong positive impression.

Common Red Flags Interviewers Notice

One thing I genuinely appreciate is when candidates openly acknowledge that they do not know something. No one is expected to know everything, and honesty often creates a positive signal.

As an experienced interviewer, it is usually easy to identify when a candidate is trying to bluff or exaggerate. If a candidate does not know a concept but can reason through it logically, that is still a much better signal than pretending to know something they do not.

Some other common red flags interviewers notice include:

• Being defensive when challenged instead of engaging with the feedback

• Claiming ownership of a project without clearly explaining their personal contribution

• Over-engineering simple problems

• Blaming others when describing past projects

• Ignoring edge cases

• Not testing the solution

A strong interview is not about appearing perfect. It is about being thoughtful, honest, structured, and open to feedback. Candidates who can acknowledge gaps, clarify their thinking, and recover gracefully from mistakes often leave a much better impression than candidates who try to force confidence without substance.

How Behavioral Interviews are Assessed

At Amazon, Leadership Principles are extremely important and are evaluated with the same seriousness as technical skills. Behavioral interviews are not casual conversations; they help interviewers understand how a candidate has acted in real situations and whether those behaviors align with the role’s expectations.

A strong answer is usually well-structured using the STAR format: Situation, Task, Action, and Result. Candidates should clearly explain the context, their specific responsibility, the actions they took, and the outcome they achieved.

A couple of things tend to weaken behavioral answers. Repeating the same example for multiple questions can be a weak signal, since it may suggest limited experience or thin preparation. Vague answers without concrete details also make it hard to assess what the candidate actually contributed.

Data matters here. Strong candidates quantify impact where possible, such as improved latency, reduced cost, saved time, increased adoption, or better customer experience. Strong behavioral answers are specific, authentic, and backed by measurable outcomes.

What Candidates Misunderstand About Interviews?

One common misunderstanding candidates have is that interviews are only about getting the correct answer.

In reality, interviewers are equally interested in how the candidate approaches the problem, clarifies requirements, communicates their thought process, and handles feedback.

Another misconception is that taking hints is a negative signal. Getting stuck can happen to anyone. What matters more is how the candidate responds: whether they listen carefully, adapt their approach, and continue reasoning logically. Many candidates also underestimate behavioral interviews.

At companies like Amazon, Leadership Principles are evaluated very seriously, and behavioral rounds can carry as much weight as technical rounds.

Candidates sometimes believe they need to appear perfect, but honesty is more valuable than pretending to know everything. A candidate who acknowledges gaps and reasons through uncertainty often creates a stronger impression than someone who tries to bluff.

A strong interview is not a performance of perfection; it is a demonstration of clarity, ownership, problem-solving, and self-awareness.

Advice to Candidates From an Interviewer

My biggest piece of advice to candidates is to treat the interview like a collaborative problem-solving discussion, not a test where you have to prove you know everything. Start by clarifying the requirements, state your assumptions, and explain your thought process clearly as you move toward a solution.

Do not rush to the answer. Interviewers care about how you think, how you handle ambiguity, and how you respond when challenged. If you get stuck, stay calm, listen to hints, and use them to adjust your approach.

For behavioral interviews, prepare multiple examples from your experience and structure them using the STAR format. Be specific about your personal contribution, the tradeoffs you made, and the impact you created. Whenever possible, support your answers with data.

Most importantly, be honest. If you do not know something, acknowledge it and reason through it logically. Strong candidates are not perfect; they are clear, thoughtful, coachable, and self-aware!

Thank you for reading!

In this article, we w’ll cover 20 most important networking concepts divided into 5 groups: Addressing, Packets and Layers, Protocols, Infrastructure, and Performance.

Let’s start with the most basic question: how do devices find each other?

Addressing

1. IP Address

Every device on a network needs an address so other devices can find it. That address is called an IP address.

There are two versions in use:

• IPv4 looks like 142.250.80.46. It uses four numbers from 0 to 255 and supports about 4.3 billion addresses.

• IPv6 looks like 2001:db8:85a3::8a2e:370:7334. It uses a much larger address space built for the modern internet.

IP addresses can also be public or private.

Your laptop:    192.168.1.10     private
Home router:    73.128.42.15     public
Google server:  142.250.80.46    public

Your laptop uses a private IP inside your home network. Your router has a public IP on the internet and translates traffic between the two.

But nobody wants to memorize IP addresses for every website server.

That is where DNS comes in.

2. DNS

DNS, or Domain Name System, translates a human-friendly name like google.com into an IP address like 142.250.80.46.

First, the browser and operating system check if they already know the answer. If not, the request goes to a recursive resolver, usually run by your ISP or a public provider like Google DNS.

The resolver then walks the DNS hierarchy: root server, TLD server like .com, and finally the authoritative name server for the domain.

The result is cached at multiple levels, so most DNS lookups are fast.

DNS and IP get traffic to the right machine. But a machine runs many programs, so how does traffic reach the right one?

Share

3. Ports

An IP address gets traffic to the right machine. A port gets it to the right program on that machine.

Ports are numbers from 0 to 65535. Some common ports are:

• 22: SSH

• 53: DNS

• 80: HTTP

• 443: HTTPS

• 5432: PostgreSQL

• 6379: Redis

When you visit a website, your browser connects to port 443 by default.

A server is usually identified by an (IP, port) pair. That is why two web servers on the same machine need different ports, like 8080 and 8081.

Now we know how to reach the right machine and process. But inside a local network, how does traffic find the right physical device?

4. MAC Address

A MAC address is a hardware address assigned to a network interface, usually written like a4:83:e7:1b:22:9c.

IP addresses help route traffic across networks. MAC addresses help deliver traffic inside the same local network, like your home Wi-Fi or office LAN.

When your laptop wants to talk to another device on the same network, it uses ARP to ask:

Who has IP 192.168.1.20?

The device with that IP replies with its MAC address. The switch then uses that MAC address to forward the data to the right device.

IPs can change when you move networks or get a new DHCP assignment. MAC addresses are meant to be fixed, though modern devices often randomize them on public Wi-Fi for privacy.

You rarely configure MAC addresses yourself, but you may see them in DHCP reservations, firewall rules, and switch settings.

5. NAT

Most homes have many devices but only one public IP address. NAT, or Network Address Translation, lets all those devices share that one public IP.

When your laptop sends a request to the internet, the router replaces the private IP and port with its own public IP and a new port.

192.168.1.10:51234  →  73.128.42.15:40001
192.168.1.11:49876  →  73.128.42.15:40002

The router stores this mapping in a NAT table, so when responses come back, it knows which internal device should receive them.

From the internet’s point of view, it looks like one machine making many connections.

NAT helped IPv4 survive the address shortage. It is also one reason peer-to-peer connections are harder, because two devices behind NAT cannot always connect directly without help.

6. DHCP

DHCP, or Dynamic Host Configuration Protocol, gives a device its network settings automatically when it joins a network.

Without DHCP, you would have to manually configure the IP address, subnet mask, default gateway, and DNS server for every device.

The DHCP flow is often called DORA:

• Discover: Client asks, “Is there an IP for me?”

• Offer: DHCP server offers an available IP

• Request: Client asks to use that IP

• Acknowledge: Server confirms and records the lease

The IP is usually leased for a limited time. When the lease is close to expiring, the device renews it.

Packets and Layers

7. Packets

Data does not travel across a network as one big blob. It is broken into smaller chunks called packets.

Each packet carries metadata, such as source IP, destination IP, sequence number, and a small part of the actual data.

Example:

Message: "Hello, this is a long message from the server"

Packet 1: seq=1, data="Hello, thi"
Packet 2: seq=2, data="s is a lon"
Packet 3: seq=3, data="g message "
Packet 4: seq=4, data="from the s"

Packets may take different routes, arrive out of order, or get dropped. The receiving side has to put them back together.

That is why the transport layer matters.

8. OSI Model

The OSI model is a 7-layer mental model for how networking is organized. Real systems often use the simpler TCP/IP model, but OSI is still useful vocabulary.

Each layer only depends on the layer above and below it. HTTP does not need to know how IP routing works. TCP does not care whether bytes travel over Wi-Fi, Ethernet, or fiber.

That separation is why you can change the underlying network without rewriting your application.

For most engineers, layers 3, 4, and 7 matter the most:

• Layer 3: IP and routing

• Layer 4: TCP and UDP

• Layer 7: HTTP, DNS, and application protocols

9. Subnetting and CIDR

A subnet is a smaller logical slice of an IP network. Subnetting lets us split one large network into smaller, manageable parts.

CIDR is the notation used to describe those slices.

Example: 192.168.1.0/24

Here, /24 means the first 24 bits identify the network. The remaining bits are used for devices inside that network.

Subnetting is common in cloud networks. For example, you might create a production VPC as 10.0.0.0/16 and give each availability zone a smaller slice.

It also makes firewall rules cleaner:

Allow 10.0.1.0/24 to access the database

That is much better than listing hundreds of IP addresses manually.

10. Router vs Switch

Routers and switches both move traffic, but they work at different layers.

A switch works at layer 2. It connects devices inside the same local network and forwards data using MAC addresses.

A router works at layer 3. It connects different networks and forwards packets using IP addresses.

Your home router is usually a router, switch, and Wi-Fi access point combined in one box.

Switches keep local traffic fast. Routers decide where packets should go next, including across the internet.

Protocols

11. TCP vs UDP

At the transport layer, the two most common protocols are TCP and UDP.

TCP is reliable. It creates a connection before sending data, tracks what was sent, retries lost data, and delivers everything in order.

Use TCP when correctness matters: web pages, APIs, databases, SSH, and file transfers.

UDP is lighter and faster. It sends data without creating a connection, and it does not guarantee delivery or ordering.

Use UDP when low latency matters more than perfect reliability: video calls, DNS, online gaming, and live telemetry.

Modern protocols like QUIC, used by HTTP/3, are built on UDP. They keep UDP’s speed benefits while adding reliability at the protocol level.

12. HTTP / HTTPS

HTTP is the request-response protocol behind the web.

A client sends a request. The server sends back a response with a status code, headers, and a body.

HTTP is stateless. Each request is independent, so cookies, sessions, and tokens are used to remember who the user is between requests.

HTTPS is HTTP over TLS.

The request format stays mostly the same, but the connection is encrypted and the server’s identity is verified.

For public websites and APIs, HTTPS is the default today. Plain HTTP should be treated as the exception.

13. TLS

TLS, or Transport Layer Security, is what puts the S in HTTPS.

It gives HTTPS three important guarantees:

• Confidentiality: Others cannot read the data

• Integrity: Data cannot be silently changed in transit

• Authenticity: The server is really who it claims to be

At a high level, the TLS handshake works like this:

The server certificate is signed by a trusted Certificate Authority. The browser verifies it before trusting the connection.

After the handshake, both sides use fast symmetric encryption for the actual data transfer.

TLS 1.3 made this process much faster by reducing the number of round trips. With session resumption, repeat connections can be even faster.

14. WebSocket

HTTP is request-response. The client asks, the server replies.

That works well for normal web pages and APIs, but not for apps where the server needs to push updates instantly, like chat, live scores, trading dashboards, multiplayer games, or collaborative editing.

A WebSocket is a persistent, two-way connection between a client and server.

It starts as an HTTP request and then upgrades to a WebSocket connection:

After the upgrade, both sides can send messages anytime without creating a new HTTP request for every update.

Use WebSockets when you need real-time, two-way communication.

For one-way server-to-client updates, Server-Sent Events, or SSE, is often a simpler option.

Infrastructure

15. Firewall

A firewall controls which network traffic is allowed in or out.

It checks traffic against rules based on fields like source IP, destination IP, port, and protocol.

ALLOW tcp from any to 10.0.1.0/24 port 443
ALLOW tcp from 10.0.0.0/16 to 10.0.2.10 port 5432
DENY  all from any to any

The last rule is important: block everything that is not explicitly allowed.

Firewalls can be stateful or stateless.

A stateful firewall tracks active connections. If your server sends a request out, the response is allowed back in automatically.

A stateless firewall checks each packet independently. It is simpler, but less flexible.

In cloud platforms, you usually see firewalls as security groups in AWS, NSGs in Azure, or firewall rules in GCP.

16. VPN

A VPN, or Virtual Private Network, creates an encrypted tunnel over the public internet.

It makes a remote device behave as if it is connected to a private network.

Two common use cases:

• Corporate VPN: Lets employees access internal company systems from outside the office

• Consumer VPN: Routes traffic through a VPN provider to hide the user’s public IP or change apparent location

VPNs are built using protocols like WireGuard, OpenVPN, or IPsec.

The key idea is simple: traffic goes through an encrypted tunnel before reaching the destination.

But a VPN does not make you fully anonymous. The VPN provider can still see where your traffic is going, so you are shifting trust from your ISP or network provider to the VPN provider.

17. Proxy vs Reverse Proxy

A proxy sits between a client and a server. The difference is which side it represents.

A forward proxy sits in front of clients. It forwards client requests to the internet.

Companies use forward proxies for content filtering, caching, and hiding internal IPs.

A reverse proxy sits in front of servers. Clients send requests to the reverse proxy, and it forwards them to the right backend server.

Reverse proxies are common in production systems. They can terminate TLS, cache responses, rate-limit clients, and route traffic to different backend services.

Tools like Nginx, HAProxy, Envoy, and Cloudflare often work as reverse proxies.

18. Load Balancer

Once you have multiple backend servers, you need a way to spread traffic across them. That is what a load balancer does.

A load balancer is usually a reverse proxy that decides which backend should handle each request.

Common algorithms:

• Round robin: Send each request to the next server

• Least connections: Send traffic to the server with the fewest active connections

• IP hash: Send the same client IP to the same server

• Weighted: Send more traffic to stronger servers

Load balancers also run health checks. If a server stops responding, the load balancer removes it from rotation and sends traffic to healthy servers.

This is how one bad instance does not bring down the whole service.

19. CDN

A CDN, or Content Delivery Network, is a group of servers spread across the world that cache content close to users.

Instead of every request going back to the origin server, the CDN serves cached content from a nearby edge location.

This reduces latency because data travels a shorter distance.

CDNs are commonly used for static assets like images, CSS, JavaScript, and video. Modern CDNs can also cache API responses, terminate TLS, run edge functions, and help absorb DDoS attacks.

Performance

20. Latency vs Bandwidth vs Throughput

Latency, bandwidth, and throughput are often mixed up, but they mean different things.

• Latency: How long one packet takes to travel from source to destination

• Bandwidth: The maximum amount of data a network can carry per second

• Throughput: The actual amount of data transferred per second

More bandwidth does not always reduce latency.

A 1 Gbps connection can still feel slow if the server is on the other side of the world.

In system design:

• Caches and CDNs reduce latency.

• More servers and network capacity increase bandwidth.

• Compression, fewer round trips, and better protocols improve throughput.

Good systems optimize all three, but they are not the same thing.

Thank you for reading!

This paper, titled ‘Attention Is All You Need’, introduced the Transformer architecture that powers all frontier LLMs of today. In this lesson, we will simply understand how this architecture works and enables LLMs to understand language so well.

The birth of Transformers

The Attention Is All You Need paper introduced the Transformer architecture for language translation tasks. It consisted of:

• Encoder block: That accepts an input to be translated

• Decoder block: That returns the translated input as an output

This architecture was modified for text generation tasks. This involved removing the Encoder and adopting a Decoder-only architecture. This Decoder-only transformer is the one that is used by modern LLMs.

Let’s learn what components make the Decoder-only Transformer so impressive.

The components of the Decoder-only Transformer

A Decoder-only Transformer is composed of multiple identical Decoders stacked on top of each other (the output of one is passed as input to the next).

Each Decoder consists of 4 components:

1. Causal (or Masked) Multi-Head Self-Attention

2. Feed-Forward Network

3. Layer Normalization

4. Residual or Skip connections

The above architecture is from GPT-1, published in 2018. Since then, it has been seen that applying Layer Normalization before Causal Multi-Head Self-Attention and Feed-Forward Network, an architecture pattern called Pre-LayerNorm, leads to better training performance. Hence, modern LLMs use the Pre-LayerNorm architecture.

Let’s learn the role of each of these components in detail next.

1. Causal (or Masked) Multi-Head Self-Attention

Attention helps a model learn dependencies between different tokens so that it can understand context, syntax, and semantics in text well.

The term “Causal (or Masked) Multi-Head Self-Attention” is understood better when we break it down into parts as follows:

• Attention: This general architecture allows tokens across different text sequences to focus on one another.

• Self-Attention: This is when Attention is applied in a way that lets tokens in the same text sequence focus on each other.

• Multi-Head Self-Attention: This architecture extends Self-Attention by using multiple parallel Self-Attention blocks (heads), rather than a single one. This helps it to better learn different types of semantic relationships within the input text sequence.

• Causal (or Masked) Multi-Head Self-Attention

  Decoder-only Transformer based LLMs generate text tokens one at a time, keeping past tokens as context at each step of generation.

  
  During training, for a given input sequence, they must learn to generate each token based on previous tokens, without peeking at future tokens.
  
  Consider this training text sequence: “The sky is blue”

  
  During training to generate the token “is“, the model can learn to generate it from both the past tokens (”The“ and “sky“) and future ones (”blue“).

  
  During generation, since the model has no access to future tokens (it hasn’t generated them yet), it can’t use the strategy of generating text from them, leading it to perform poorly. Hence, we need an Attention mechanism that can mask future tokens during training.

  This is made possible using the Causal or Masked Multi-Head Self-Attention, which ensures that each token in the training sequence can attend only to previous tokens and itself, not to future tokens.

Each of these attention mechanisms is Scaled dot-product attention, mathematically, as shown below.

The internals of the Causal multi-head self-attention mechanism are shown below.

Modern LLMs use many other variants of the attention mechanism, such as:

• Grouped query attention (GQA) as in Meta Llama

• Multi-head Latent Attention (MLA) as in DeepSeek-V3

• Compressed Sparse Attention (CSA) and Heavily Compressed Attention (HCA) as in DeepSeek-V4

2. Feed-Forward Network

While the role of the Causal Multi-Head Self-Attention is to understand inter-token patterns (between different tokens) in text, the Feed-forward network (FFN) helps learn token-wise patterns or deeper individual representations of tokens.

The following Feed-forward network expands the input dimension using fully connected layers to increase representational capacity, then projects it back to the original dimension before passing it to the next layer.

A feed-forward network can use multiple wide, fully connected layers, along with different activation functions such as SwiGLU. A simple feed-forward network is shown below.

3. Layer Normalization

Layer Normalization, or LayerNorm, helps stabilize and speed up model training by keeping each token’s representation well-scaled and gradients numerically stable as they flow through the layers of a Transformer.

It does so by normalizing each token’s feature vector to zero mean and unit variance, then applies learned scaling and shifting.

There are two ways in which LayerNorm is used:

1. Post-LayerNorm (Post-LN): where LayerNorm is applied after each sublayer as in the original Transformer paper.

2. Pre-LayerNorm (Pre-LN): where LayerNorm is applied before each sublayer, as in architectures like GPT-2, leading to more stable gradients during training.

Many modern LLMs, such as Qwen 3, use RMSNorm with pre-normalization instead of Pre-LayerNorm because it is computationally cheaper and offers faster training and inference while maintaining comparable model performance.

4. Residual/ Skip connection

A Residual or Skip connection adds the input of a layer directly to its output, bypassing the layer.

Such connections help information and gradients flow through deep networks, making training more stable and effective.

Residual connections were first implemented in Image recognition models, and given their effectiveness, they are now used in all LLMs today, either in their original form or a modified form such as:

• Hyper-Connections

• Manifold-Constrained Hyper-Connections as in DeepSeek-V4

All of the above-described components come together to form the Decoder-only Transformer, an architecture that lies at the heart of modern LLMs.

The flow through an LLM goes like this:

• An input sequence is tokenized (broken down into tokens) and converted into input embeddings (which contain a high-dimensional representation of input tokens and their positions in the sequence)

• These are processed by a stack of Decoder blocks in a Decoder-only transformer

• A Layer Normalization is applied to the output of the transformer stack

• A Linear output layer takes the last token’s vector and turns it into a list of logits

• These logits are converted into token probabilities

• Different decoding strategies are used to pick a token from these probabilities. This is the next token produced by the LLM, given the input sequence.

A more detailed illustration of each component is shown below.

If you’re curious about learning more about these components and how a complete LLM works and is trained, with code, this series of articles will help.

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 as the product grows, that simplicity can become a bottleneck. Teams step on each other’s code, deployments become risky, and one small change can affect the entire system. That is when many teams start looking at microservices.

Microservices can help, but they also introduce distributed systems complexity: network failures, data consistency challenges, observability overhead, and more operational burden.

This is where modular monoliths offer a middle path. They keep the simplicity of a monolith while adding stronger internal boundaries and clearer ownership.

In this article, we will break down monoliths, microservices, and modular monoliths, understand how they differ, when each one makes sense, how to choose the right architecture for your system, and how to migrate between these architectures.

What is a Monolith?

A monolithic application is built and deployed as a single unit.

The UI, business logic, and data access code all live in the same codebase. They are compiled into one artifact, deployed together, and usually run as one process.

Different parts of the application communicate through direct function calls and often share the same database.

For example, a simple e-commerce monolith might organize code by technical layers:

ecommerce-app/
├── controllers/
├── services/
├── repositories/
└── models/

This structure is easy to understand in the early stages of a product. You clone one repository, run one application, connect one database, and start building.

That simplicity is the biggest strength of a monolith.

There is one codebase to maintain, one deployment pipeline to manage, one process to monitor, and one place to look when something breaks. Database transactions are straightforward, and communication between modules is fast because it happens through normal function calls, not network requests.

But the same simplicity can become painful as the system grows.

A small change in one module may require rebuilding, retesting, and redeploying the entire application. If one module gets heavy traffic, you often have to scale the whole app. One bad query, memory leak, or unhandled exception can affect the entire system. Over time, internal boundaries can blur, and developers may start reaching across modules directly.

Almost every successful application starts as a monolith. The real question is not whether monoliths are bad. The real question is: what should you do when the monolith starts slowing you down?

What is a Microservices Architecture?

Read more

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