The Model Context Protocol (MCP) is an open standard created by Anthropic that provides a universal interface for connecting AI models to external data sources, tools, and services.

Think of it as a USB-C port for AI -- one standardized protocol instead of custom integrations for every tool.

Core Capabilities

MCP Architecture

Host               MCP Client           MCP Server          Data Sources
(Claude Desktop,   (1:1 connection      (Exposes tools,     (APIs, DBs,
 IDE, custom app)   per server)          resources &          filesystems,
                                         prompts)            SaaS services)
      |                  |                    |                    |
      | ──── creates ──> |                    |                    |
      |                  | ── JSON-RPC 2.0 ─> |                    |
      |                  |                    | ── queries/calls ─>|
      |                  |                    | <── responses ──── |
      |                  | <── responses ──── |                    |
      | <── displays ─── |                    |                    |

• Host -- The user-facing application (e.g. Claude Desktop, VS Code, a custom app). Creates and manages MCP clients.
• Client -- Lives inside the host. Each client holds a stateful 1:1 session with one MCP server. Handles capability negotiation and message routing.
• Server -- A lightweight process that exposes tools, resources, and prompts over the MCP protocol. Can be local or remote.

MCP Transport Modes

1. stdio (Local Only)

Communication over standard input/output streams. The host spawns the server as a child process. Simplest setup -- no networking needed.

Best for: Local tools, CLI integrations, IDE extensions, development workflows.

2. SSE -- HTTP + Server-Sent Events (Remote / Legacy)

Client sends requests via HTTP POST and receives streaming responses over an SSE channel. Works over the network.

Best for: Remote servers, web-based clients, existing HTTP infrastructure.

3. Streamable HTTP (Recommended)

The latest spec transport. Pure HTTP with optional streaming via SSE. Supports both stateful sessions and stateless request/response patterns.

Best for: Production deployments, scalable architectures, cloud-native services.

All transports use JSON-RPC 2.0 as the message format. The protocol supports three message types: requests (expect response), responses (reply to request), and notifications (fire-and-forget).

Performance Benchmarks

Test Overview

Benchmark Tools Used

Each MCP server implemented 4 tool types covering different workload profiles:

Latency & Throughput

• Java & Go deliver ~3x the throughput of Node.js and ~5.5x of Python
• Python is ~31x slower than Go/Java; Node.js is ~12x slower

Resource Utilization

• Go uses just 18 MB of memory -- 12.5x less than Java, with identical throughput
• Go delivers 12.8x more throughput per MB than Java -- crucial for container/K8s environments

Tool-Specific Latency (ms)

• DB-bound operations narrow the gap; compute & I/O tasks show the widest spread

Key Findings

1. Java & Go are effectively tied on latency and throughput -- both deliver sub-millisecond averages and 1,624 RPS.
2. Go's memory footprint is dramatically lower at 18 MB vs Java's 226 MB -- a 12.5x advantage for containerized workloads.
3. Node.js & Python consume >93% CPU under load while Java and Go remain under 32%, leaving significant headroom.
4. Node.js is 10-12x slower due to per-request MCP server instantiation for security isolation.
5. All implementations achieved a 0% error rate across 3.9M requests -- stability is not the differentiator.

Production Recommendations

Go -- Cloud-Native & Cost-Optimized

Best for Kubernetes, horizontal scaling, and cloud deployments. 12.8x better memory efficiency than Java means fewer pods and lower infrastructure cost.

Java -- Lowest Latency & Mature Ecosystem

Best when absolute lowest latency matters and your team needs a rich ecosystem for complex business logic. Higher memory cost is the trade-off.

Node.js -- Moderate Traffic (<500 RPS)

Viable for teams with existing JavaScript expertise. Security-focused per-request isolation adds overhead -- acceptable at moderate scale.

Python -- Dev / Test / Low Traffic

Best suited for development, testing, prototyping, or very low-traffic scenarios (<100 RPS). Not recommended for production workloads at scale.

Conclusion

• For maximum efficiency --> Go
• For lowest latency + ecosystem depth --> Java
• For moderate loads with JS teams --> Node.js
• Keep Python for dev & prototyping

What is Consistent Hashing?

To understand consistent hashing, it is helpful to first examine traditional hashing and its limitations.

Traditional Hashing:

In traditional hashing, a hash function maps keys directly to buckets (nodes).

Hash Functions are any functions that map value from an arbitrarily sized domain to another fixed-sized domain, usually called the Hash Space. The values generated as an output of these hash functions are typically used as keys to enable efficient lookups of the original entity.

For example:

• • Suppose you have a Distributed File Store system where users can upload and read files. The files are stored across 4 servers, and the hash function assigns files to servers using the formula hash(fileName) % number_of_servers.

    • If the number of servers is 4, and hash(fileName) returns 9 for a specific file (e.g., "image.png"), it will be stored in server 9 % 4 = 1. Similarly, a request to read "image.png" will also be routed to server 1 using the same logic.

Limitations of Traditional Hashing:

1. High Disruption with Node Changes:

   • If a new server is added or an existing server is removed, almost all keys need to be rehashed and redistributed.

     • For example, consider a Distributed File Store system where users upload and read files, and files are distributed across 4 servers using hash(fileName) % 4. If a new server is added (making it 5 servers), the formula changes to hash(fileName) % 5. As a result, files previously mapped to a specific server will now likely be assigned to different servers. For instance, a file that was on Server 3 with hash(fileName) % 4 = 3 might now be moved to Server 4 with hash(fileName) % 5 = 4.

   • This results in significant overhead and potential performance degradation.

2. Load Imbalance:

   • If the hash function does not distribute keys evenly, some servers may become overloaded while others remain underutilized.

3. Scalability Issues:

   • Scaling up or down in response to load is not seamless due to the need for global rehashing.

How Consistent Hashing is Better:

Consistent hashing addresses these issues by using a different approach. Instead of directly mapping keys to nodes, both keys and nodes are placed on a virtual ring. Keys are assigned to the nearest node in the clockwise direction.

When the nodes are added to the virtual ring, only the keys mapped to the adjacent nodes will be remapped. Similarly, when nodes are removed from the virtual ring, only the keys of the removed node will be remapped. This approach ensures that when a node is added or removed, only a subset of keys needs to be remapped, making the system more resilient to changes.

The Key Idea:

• The hash space is visualised as a circle (0 to 2^m - 1, where m is the number of bits in the hash).

• Each node (e.g., server) is assigned a position on the circle using a hash function.

• Each key is also assigned a position on the circle.

• A key is assigned to the first node clockwise from its position.

Example

Suppose we have three servers (A, B, and C) in a distributed file storage system, where users upload and read files, and we use consistent hashing to distribute files.
We created 2 virtual nodes of each server so that load will distribute among them evenly and reducing the possibility of cascading failure.

1. Step 1: Assign Nodes to the Ring

   • Server N1a,N2b,N3c is hashed to position 10, 60 and 80.

   • Server N2a, N2b, N3c is hashed to position 30,90 and 110.

   • Server N3a,N3b,N3c is hashed to position 120, 20 and 50.

   • Server N4a,N4b,N4c is hashed to position 40, 70 and 100.

2. Step 2: Map Files to the Ring

   • File F1 ("image1.png") is hashed to position 5.

   • File F2 ("doc1.pdf") is hashed to position 25.

   • File F3 ("video1.mp4") is hashed to position 70.

3. Step 3: Place Files

   • F1 (position 5) is assigned to Server N1a (first node clockwise).

   • F2 (position 25) is assigned to Server N2a.

   • F3 (position 70) is assigned to Server N4b.

Adding a new Node

Suppose a new server, N5, is added and hashed to position 27.

Only one file (F2 position 25) is reassigned to N5, illustrating minimal disruption.

Removing a Node

Suppose a Server N4 is down and removed. Keys mapped to Server N4 will be remapped.
Only File F3(position 70) will be reassigned to Server N1c.

Implementation Details

Here is a basic Java implementation of consistent hashing:

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.*;

public class ConsistentHashing {
    private final int numReplicas;
    private final SortedMap<Integer, String> ring;

    public ConsistentHashing(int numReplicas) {
        this.numReplicas = numReplicas;
        this.ring = new TreeMap<>();
    }

    // Hash function - MD5
    private int hash(String key) {
        try {
            MessageDigest md = MessageDigest.getInstance("MD5");
            byte[] digest = md.digest(key.getBytes());
            return ((digest[0] & 0xFF) << 24) | ((digest[1] & 0xFF) << 16) | ((digest[2] & 0xFF) << 8) | (digest[3] & 0xFF);
        } catch (NoSuchAlgorithmException e) {
            throw new RuntimeException(e);
        }
    }

    // Adding new node in the ring
    public void addNode(String node) {
        for (int i = 0; i < numReplicas; i++) {
            String replicaKey = node + ":" + i;
            ring.put(hash(replicaKey), node);
        }
    }

    // Removing node from the ring
    public void removeNode(String node) {
        for (int i = 0; i < numReplicas; i++) {
            String replicaKey = node + ":" + i;
            ring.remove(hash(replicaKey));
        }
    }

    // Get the node/server to map the given key/value
    public String getNode(String key) {
        if (ring.isEmpty()) {
            return null;
        }
        int hashKey = hash(key);
        if (!ring.containsKey(hashKey)) {
            SortedMap<Integer, String> tailMap = ring.tailMap(hashKey);
            hashKey = tailMap.isEmpty() ? ring.firstKey() : tailMap.firstKey();
        }
        return ring.get(hashKey);
    }

    public static void main(String[] args) {
        ConsistentHashing ch = new ConsistentHashing(3);
        ch.addNode("A");
        ch.addNode("B");
        ch.addNode("C");

        System.out.println(ch.getNode("K1")); // Node responsible for K1
        System.out.println(ch.getNode("K2")); // Node responsible for K2

        ch.addNode("D"); // Add a new node
        System.out.println(ch.getNode("K2")); // Node responsible for K2 after adding D
    }
}

Benefits of Consistent Hashing

1. Minimal Key Movement:

   • When a node joins or leaves, only a small portion of keys are remapped. This is in contrast to traditional hashing, where all keys might need to be redistributed.

2. Load Balancing:

   • Keys are distributed across nodes more evenly, especially when using techniques like virtual nodes (assigning multiple positions for each physical node on the ring).

3. Scalability:

   • Adding or removing nodes is seamless, making consistent hashing ideal for systems with dynamic scaling requirements, such as cloud-based applications.

4. Fault Tolerance:

   • When a node fails, its keys are redistributed to adjacent nodes on the ring, ensuring system continuity.

Comparison with Other Hashing Techniques

Applications of Consistent Hashing

1. Distributed Caching:

   • Systems like Memcached and Redis use consistent hashing to distribute keys across nodes.

2. Load Balancers:

   • Consistent hashing helps in assigning incoming requests to servers in web applications.

3. Distributed Databases:

   • Databases like Cassandra and DynamoDB leverage consistent hashing for data partitioning and replication.

Conclusion

Consistent hashing is a cornerstone of modern distributed systems, enabling efficient and resilient data placement. Its ability to handle dynamic changes with minimal disruption makes it a go-to strategy for scalable and fault-tolerant applications.

Whether you’re building a distributed cache, a load balancer, or a database, understanding and implementing consistent hashing can significantly enhance your system's performance and reliability.

What is Retrieval Augmented Generation (RAG)?

Retrieval Augmented Generation (RAG) is an approach where a generative model doesn't rely solely on its learned parameters but instead enhances its output by retrieving information from a large corpus of data. The retrieval process ensures that the AI system has access to the most up-to-date and accurate information during its response generation.

Traditional models often struggle with answering questions that require factual knowledge not seen during training, leading to hallucinations or incorrect answers. RAG improves upon this by using an external database to retrieve relevant information and passing that information to the generative model for more context-aware and grounded responses.

How Does RAG Work?

1. Query Input: A user inputs a query, much like any other question or request posed to a system.

2. Retrieval: The system first searches an external source of knowledge (like a vector database) for documents, texts, or passages related to the query.

3. Document Ranking: Using techniques like semantic search or nearest neighbor search, relevant documents are ranked and selected based on how similar they are to the query.

4. Generation: The retrieved documents are then passed as context to a generative model, like GPT-3 or GPT-4. This model uses the retrieved information along with its internal knowledge to generate a well-informed, accurate response.

5. Response Output: The generative model creates a response that incorporates the retrieved information, ensuring it is grounded in facts and highly relevant to the user's query.

The Role of Vector Databases in RAG

Vector databases play a critical role in the retrieval process of RAG. These databases store embeddings (dense vector representations) of large datasets, which makes it easy to perform efficient similarity searches.

When a query is inputted, it is transformed into a vector through a process known as embedding. This vector is then compared against the vectors stored in the database to find the most relevant documents. Vector databases are optimized for this task, offering high-performance similarity search capabilities. Some popular vector databases include:

• FAISS (Facebook AI Similarity Search): An open-source library that allows fast similarity search in high-dimensional spaces.

• Pinecone: A managed vector database service that offers scalable similarity search.

• Weaviate: An open-source vector search engine that can integrate with various machine learning models.

These vector databases help ensure that RAG can retrieve the most relevant documents in real-time, even from massive data corpora.

Vector Representation of Texts

To efficiently perform search, text data (such as documents, articles, or websites) must be converted into vectors. This is done using embedding models like Sentence-BERT or OpenAI’s embedding models. These models convert each piece of text into a vector of fixed dimensionality, which can then be indexed by the vector database. Similarity measures such as cosine similarity or Euclidean distance are used to rank the retrieved documents.

A Practical Example of RAG with Vector Databases and AI Agents

Let’s consider an example of a chatbot built using RAG with a vector database and AI agent:

Scenario: An AI-powered Virtual Assistant for Technical Support

Imagine you are building a virtual assistant for technical support in a software company. Users will ask questions about the software’s features, installation guides, troubleshooting steps, etc.

Here’s how RAG can be used:

1. User Query: "How do I install the software on Linux?"

2. AI Agent: The AI agent processes the query, recognizes that the user is asking about software installation on a Linux system, and formulates a precise query for the vector database: "Linux installation guide for software."

3. Retrieval: The vector database retrieves relevant documents, such as installation guides, forums, or knowledge base articles related to Linux installations.

4. Generation: The generative model takes these documents and crafts a coherent, step-by-step installation guide tailored to the user’s query.

5. Response: The AI agent outputs: "To install the software on Linux, follow these steps... [steps from the retrieved guide]"

The AI agent ensures the process is seamless and context-aware, making it easy for the user to get accurate and relevant answers without needing to sift through long documentation.

Implementation

To implement the example you described using LangChain and a vector database, you can follow the steps outlined below. We will break down the process into key components:

1. Setting up the vector database to store and retrieve relevant documents.

2. Integrating LangChain to connect the vector database with a language model for retrieval-augmented generation (RAG).

3. Building the AI Agent that processes the user query, retrieves relevant data, and generates a response.

Step 1: Setup Vector Database

We will use FAISS (Facebook AI Similarity Search) or Pinecone as the vector database to store document embeddings. First, we need to create embeddings for your documents and store them in the database.

from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import FAISS
import faiss
import os

# Initialize OpenAI embeddings model (or any other model)
embeddings = OpenAIEmbeddings()

# Initialize the vector store (FAISS in this case)
faiss_index = FAISS.load_local("path/to/faiss_index")  # Load or create your FAISS index

# Assuming documents are available as a list of strings
documents = [
    "Linux installation guide for software...",
    "How to troubleshoot software on Linux...",
    "Windows installation steps for software...",
    # more documents here
]

# Create embeddings for documents
doc_embeddings = embeddings.embed_documents(documents)

# Store documents in the FAISS index
faiss_index.add(np.array(doc_embeddings).astype(np.float32))  # FAISS index requires float32 embeddings

Step 2: Retrieval-augmented Generation (RAG) Setup

Now we integrate LangChain to allow the agent to retrieve relevant documents from the vector database and generate responses based on that.

from langchain.chains import RetrievalQA
from langchain.llms import OpenAI
from langchain.agents import initialize_agent
from langchain.agents import Tool

# Create a retrieval chain
retriever = faiss_index.as_retriever(search_kwargs={"k": 3})  # Retrieve top 3 results

# Use OpenAI or any other LLM for generation
llm = OpenAI(temperature=0.7)

# Create a RetrievalQA chain (combines retrieval and generation)
qa_chain = RetrievalQA(combine_docs_chain=llm, retriever=retriever)

# Define the tools for the agent (including QA system)
tools = [
    Tool(
        name="Technical Support Assistant",
        func=qa_chain.run,
        description="Retrieve technical support documents from the knowledge base."
    )
]

# Initialize the agent with the tools and an LLM
agent = initialize_agent(tools, llm, agent_type="zero-shot-react-description", verbose=True)

Step 3: Implement the AI Agent for User Queries

The agent will now be capable of handling user queries related to technical support. When a user asks, for example, "How do I install the software on Linux?", the agent will retrieve relevant documents and generate a response.

# Simulating user query
user_query = "How do I install the software on Linux?"

# Pass the query to the agent for processing
response = agent.run(user_query)

# Display the AI's response
print(response)

Final Workflow

1. User submits a query: "How do I install the software on Linux?"

2. Vector database retrieves relevant documents based on query embeddings.

3. LangChain agent processes the retrieved documents and passes them to the generative model (OpenAI, or any other model you're using).

4. AI agent generates a response combining retrieved documents in a coherent way, such as a step-by-step guide on how to install the software on Linux.

Additional Notes:

• You can store documents as embeddings in your vector database using various models, including OpenAI, SentenceTransformers, or other pre-trained models.

• Ensure the knowledge base is regularly updated to maintain accuracy and relevance.

• The agent can be enhanced with more advanced features like error handling, multi-step reasoning, or including additional tools for different types of queries.

How AI Agents Differ from Traditional LLMs

While both AI Agents and LLMs leverage natural language processing, they differ in key aspects:

Traditional LLMs require human intervention to drive conversations, whereas AI Agents can operate independently, making decisions and performing tasks dynamically.

How to Develop Custom AI Agents

Developing a custom AI Agent involves several key steps:

1. Define the Objective: Identify the purpose of the AI Agent. For example, automating customer service interactions.

2. Choose a Framework: Libraries such as LangChain, AutoGen, and OpenAI's Function Calling API can help build AI Agents.

3. Implement Memory: Utilize vector databases like Pinecone or Redis to provide persistent memory.

4. Incorporate Tools & APIs: Equip the agent with access to databases, APIs, and external tools to complete tasks.

5. Implement a Decision-Making Process: Use reinforcement learning or rule-based logic for better decision-making.

6. Deploy and Monitor: Deploy the agent to production and continuously optimize its performance.

Coding Example Using LangChain

Below is a simple example of building a custom AI Agent using LangChain:

from langchain.llms import OpenAI
from langchain.agents import initialize_agent, AgentType
from langchain.tools import Tool

# Define an LLM instance
llm = OpenAI(model_name="gpt-4")

# Define a tool for the agent to use
def fetch_ticket_availability(query):
    return "Available tickets for your destination: Flight A, Flight B, Flight C"

tool = Tool(
    name="TicketAvailability",
    func=fetch_ticket_availability,
    description="Fetch available tickets based on user query"
)

# Initialize the agent
agent = initialize_agent(
    tools=[tool],
    llm=llm,
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True
)

# Test the agent
response = agent.run("Find me flights from New Delhi to New York for next Monday")
print(response)

This example demonstrates how to integrate a LangChain-powered AI Agent with an external tool to fetch flight availability based on user input.

The agent determines whether to call a tool based on the input query and its internal reasoning process. In LangChain, this is achieved through a combination of:

1. Tool Descriptions: Each tool (like `TicketAvailability` in this case) has a description that helps the agent understand when to use it.

2. LLM Decision-Making: The agent uses an LLM to analyze the input query and decide if any tool needs to be invoked.

3. REACT Framework: LangChain's `ZERO_SHOT_REACT_DESCRIPTION` agent type follows the ReAct (Reasoning + Acting) paradigm, meaning it first reasons about the input, decides on an action, and then executes the appropriate tool.

4. Execution Flow:

- The agent receives a user query.

- It parses the intent (e.g., finding flights).

- If the query matches the function of a registered tool (e.g., fetching ticket availability), the agent calls that tool.

- The tool executes its function and returns a response.

- The agent processes the response and provides a final answer to the user.

Thus, when the user asks, *"Find me flights from New Delhi to New York for next Monday"*, the agent:

- Recognizes that the query is related to flight availability.

- Identifies `TicketAvailability` as a relevant tool.

- Calls the function `fetch_ticket_availability()`, retrieves the results, and returns them to the user.

Use Cases of AI Agents

AI Agents can be applied in multiple domains, including:

• Customer Support: Handling queries, resolving complaints, and managing bookings.

• Healthcare: Assisting with medical diagnoses and patient follow-ups.

• Finance: Providing investment recommendations and fraud detection.

• E-commerce: Offering personalized shopping assistance and order tracking.

• Software Development: Automating bug detection and generating code snippets.

Example: AI Agent for Customer Support in Online Ticket Booking

Let’s walk through an example of an AI Agent designed for customer support in an online ticket booking system.

Objective

To automate customer queries, assist with ticket bookings, cancellations, and modifications.

Architecture

1. LLM for Natural Language Understanding - GPT-based model for conversational interface.

2. Memory Store - A Redis-based database for storing user history.

3. APIs for Integration - Connecting with ticket booking systems (e.g., airline, train, event platforms).

4. Decision Engine - Rule-based or reinforcement learning model for handling customer queries.

Workflow

1. User Query: "I want to book a flight from New Delhi to New York for next Monday."

2. Intent Recognition: The agent extracts key details: origin (New Delhi), destination (New York), date (next Monday).

3. API Call: The agent fetches available flights and presents options.

4. User Confirmation: The user selects a preferred flight.

5. Booking Completion: The agent books the flight and provides a confirmation.

6. Follow-up: If needed, the agent can assist with cancellations, seat selection, or meal preferences.

Sample Implementation of AI Agent for Customer Support based on above

from langchain.chat_models import ChatOpenAI
from langchain.memory import RedisChatMessageHistory
from langchain.agents import initialize_agent, Tool
from langchain.tools import tool
import requests
import datetime

# Define a function to fetch available flights
def fetch_flights(origin, destination, date):
    # Placeholder function: Replace with actual API calls to airline or travel service
    return [
        {"flight": "AI 101", "departure": "10:00 AM", "arrival": "2:00 PM", "price": "$500"},
        {"flight": "UA 202", "departure": "1:00 PM", "arrival": "5:00 PM", "price": "$550"},
    ]

# Define a function to book flights
def book_flight(flight_id, user_details):
    # Placeholder function: Replace with actual API call to book the flight
    return {"status": "confirmed", "flight_id": flight_id, "user": user_details}

# LangChain Tool for fetching flights
@tool
def get_flights(origin: str, destination: str, date: str):
    """Fetches available flights given origin, destination, and date."""
    flights = fetch_flights(origin, destination, date)
    return flights

# LangChain Tool for booking flights
@tool
def book_flight_tool(flight_id: str = None, user_details: dict = None):
    """Books a flight given flight ID and user details. If missing, prompts user for input."""

    if not flight_id:
        return "Please provide a flight ID from the available options."

    if not user_details or "name" not in user_details or "email" not in user_details:
        return "Please provide user details including name and email."

    booking = book_flight(flight_id, user_details)
    return booking


# Memory store (Redis)
memory = RedisChatMessageHistory(url="redis://localhost:6379/0")

# Initialize LLM
llm = ChatOpenAI(model_name="gpt-4")

# Define the agent
tools = [get_flights, book_flight_tool]
agent = initialize_agent(
    tools, llm, agent="zero-shot-react-description", verbose=True, memory=memory
)

# Example query
response = agent.run("I want to book a flight from New Delhi to New York for next Monday.")
print(response)

How AI Agents handle memory

The agent writes conversation history into Redis using the RedisChatMessageHistory memory store. Specifically, it stores messages exchanged between the user and the agent, allowing the AI to maintain context across interactions.

What Gets Stored in Redis?

1. User Messages: The queries or requests made by the user (e.g., "I want to book a flight from New Delhi to New York for next Monday.").

2. Agent Responses: The replies generated by the AI (e.g., "Here are the available flights for your route.").

3. Contextual Memory: If the user continues the conversation (e.g., "Book the first one."), the agent remembers the previous flight options presented.

How Redis Stores the Data?

• The RedisChatMessageHistory class stores messages as a key-value structure in Redis.

• Each user session is typically associated with a unique key (e.g., chat:<session_id>).

• Messages are stored in chronological order, allowing retrieval for context-based responses.

Example of Stored Data in Redis

{"chat:session_123": [
        {"role": "user", "message": "I want to book a flight from New Delhi to New York for next Monday."},
        {"role": "agent", "message": "Here are the available flights: AI 101 - $500, UA 202 - $550."},
        {"role": "user", "message": "Book AI 101."},
        {"role": "agent", "message": "Your booking for AI 101 is confirmed."}
    ]
}

The agent utilizes the message history stored in Redis to maintain context and continuity in the conversation. Here’s how it works:

1. Retrieving Conversation History

The RedisChatMessageHistory memory store acts as a persistent message history. Each time the user interacts with the agent, it retrieves past interactions from Redis, allowing it to remember the conversation.

• When a user starts a new session, Redis retrieves previous messages using a unique session key (e.g., chat:<session_id>).

• The LangChain memory module feeds this history into the LLM, enabling it to generate responses based on past exchanges.

2. Contextual Understanding

Since the agent maintains history, it can:

✅ Understand Follow-up Queries
If a user says:

• User: "I want to book a flight from New Delhi to New York for next Monday."

• Agent: "Here are the available flights: AI 101 - $500, UA 202 - $550."

• User: "Book the first one."

The agent remembers "AI 101" as the first option without needing the user to repeat.

✅ Maintain Personalization
If a user previously requested vegetarian meals or window seats, the agent can recall this preference.

✅ Handle Multi-turn Conversations

• User: "What’s my booking status?"

• Agent: (retrieves previous booking confirmation) "Your flight AI 101 is confirmed."

3. How LangChain Uses History?

LangChain’s memory mechanism ensures that past interactions are passed as part of the conversation context.

• Example without memory:

  • User: "Book the first one."

  • Agent: "I don’t understand. Which flight?"

• Example with memory:

  • User: "Book the first one."

  • Agent: (Remembers previous options) "Your flight AI 101 is confirmed."

In the world of distributed systems, the CAP theorem is a fundamental concept that guides the design and architecture of these systems. Proposed by Eric Brewer in 2000, the CAP theorem states that it is impossible for a distributed system to simultaneously guarantee all three of the following properties:

1. Consistency

2. Availability

3. Partition Tolerance

Consistency

Consistency ensures that every read request reflects the most recent write.

In other words, all nodes have the same view of the data/state at any given time. When a client queries the system, it always retrieves the latest data.

Availability

Availability ensures that every request( read(recent or non-recent) or a write) always receives a response, even if there is a node failure or partition breakdown. This means remains operational providing response to any query.

Partition Tolerance

Partition tolerance guarantees that the system continues to operate despite any number of communication breakdowns/ network partitions between the nodes. In a distributed environment, network partitions are inevitable due to hardware failures, network congestion, or other issues.

Deep Dive into CAP Theorem

A distributed system always needs to be partition tolerant, we shouldn’t be making a system where a network partition brings down the whole system.
So, a distributed system is always built Partition Tolerant.

So, In simple words, CAP theorem means if there is network partition and if you want your system to keep functioning you can provide either Availability or Consistency and not both.

How a Distributed System breaks Consistency or Availability?

Scenario 1: Multi-Node system where multi nodes capable of handing read/ write and nodes failure to propagate an update request to other nodes.

Consider a cluster with two nodes, N1 and N2, both capable of handling read and write requests.

In the diagram above, N1 receives an update request for id=2, modifying the salary from 800 to 1000. However, due to a network partition, N1 cannot propagate this update to N2.

When a read request is directed to N2, the node has two possible responses:

1. Respond with its current data (salary = 800) and later update the data when the network partition is resolved. This approach makes system available but not consistent.

2. Return an error, indicating it does not have the latest data. This ensures consistency by avoiding the return of stale data but compromises availability.

Scenario 2: Single-leader system for read and write operations

In a single-leader system, all read and write operations come to the leader, while other nodes remain synchronized with the leader and act as standby nodes in case the leader fails.

The challenge arises if the leader becomes disconnected from the cluster or clients cannot connect to it due to a network partition. In such cases, the system cannot process write requests until a new leader is elected, making the system consistent but not available during the transition.

But if system allows read request from Read replica then system can response even if there is master node failure, which makes system highly available but not consistent for reads.

A single-leader system that handles both reads and writes from master, should not be classified as highly available.

RDBMS(MySQL, Oracle, MS SQL Server, etc)

It’s no brainer that all RDBMS are Consistent as all reads and writes go to a single node/server.

How about availability? You might say, it is one single server and hence a single point of failure. So, how it’s categorized under Availability?

As I said earlier CAP-Availability is not the same as day to day availability/downtime we talk about. In a single node system, there will not be any network partition hence if the node is up, it will always return success for any read/write operation and hence available.

Thus, RDMS system can be Highly available and Consistent.

Trade-offs in CAP Theorem

The CAP theorem highlights three trade-off scenarios in distributed systems:

1. Consistency and Availability (CA):
   Ensures identical data across all nodes and responsiveness to requests. Performance may be compromised during network issues to maintain data accuracy.

2. Consistency and Partition Tolerance (CP):
   Prioritizes data consistency across nodes despite network partitions. The system may become temporarily unavailable to preserve data integrity.

3. Availability and Partition Tolerance (AP):
   Focuses on staying operational during network disruptions. Sacrifices strict consistency, accepting temporary data inconsistencies to ensure accessibility.

Practical Implications

In real-world applications, the choice between consistency, availability, and partition tolerance depends on the specific use case:

• Financial Systems: Strong consistency is critical to ensure accurate transactions.

• Social Media Platforms: Prioritize availability, allowing users to interact with slightly stale data.

• Global Systems: Partition tolerance is essential to maintain operations across distributed regions.

Understanding the CAP theorem and its trade-offs helps engineers design systems that align with the unique requirements of their applications, ensuring reliability and performance in distributed environments.

Probing the CAP Theorem

1. Can you only have 2 out of 3 CAP properties?
   No, CAP means you must choose between Consistency and Availability during a partition, not abandon one entirely.

2. Does partition tolerance eliminate partition challenges?
   No, it ensures operation during partitions but doesn’t resolve consistency or availability issues.

3. Example of a non-partition-tolerant system:
   A centralized database or a multi-node system with synchronous replication halts during partitions due to dependency on full communication.

4. How to make systems partition-tolerant?

   • Use eventual consistency to allow independent node decisions and reconcile later.

   • Adopt asynchronous replication to accept writes without waiting for acknowledgment.

   • Employ quorum-based systems for majority agreement.

5. Is partition tolerance optional?
   No, distributed systems must handle partitions; the trade-off is between consistency and availability.

6. What are CA systems?
   CA systems prioritize consistency and availability but fail during partitions, making them non-partition-tolerant.

7. Does 99.999% uptime mean high availability?
   Not in CAP terms. Availability requires every request to a non-failing node to receive a valid response, even during partitions.

8. Do timeout errors count as availability?
   No, errors or timeouts compromise availability in CAP’s definition.

9. Does eventual consistency meet CAP's consistency?
   No, CAP’s consistency refers to strong consistency, which eventual consistency does not satisfy.

10. Does relaxing consistency always lead to eventual consistency?
    Not always; it might result in unresolved inconsistencies without conflict resolution mechanisms.

11. Can strong consistency be achieved with a majority quorum?
    Yes, but it sacrifices availability, adhering to CAP’s trade-offs.

12. Does CAP apply to microservices?
    Yes, CAP principles are relevant to microservices as well as distributed databases.

13. What if partition tolerance is ignored?
    Ignoring partition tolerance works in systems with reliable networks but risks failure during real-world partitions.

14. When can partition tolerance be ignored?
    In tightly controlled environments (e.g., single-node systems or highly reliable networks), partitions are negligible. Examples: MySQL on a single server or Google Spanner with controlled infrastructure.

By reducing the distance between users and servers, CDNs minimize latency, improve load times, and enhance the overall user experience.

How Does a CDN Work?

At its core, a CDN works by caching content on multiple servers spread across various geographical locations, also known as edge servers. Here’s a step-by-step breakdown of how a CDN operates:

1. Content Caching: The origin server uploads content to the CDN’s edge servers in case of Push CDN.

2. User Request: In case of Pull CDN, When a user requests a resource (e.g., a webpage or an image), the request is routed to the nearest CDN edge server based on the user's location.

3. Cache Lookup: The edge server checks if the requested content is cached.

   • If cached, the content is delivered directly to the user, ensuring minimal latency.

   • If not cached, the edge server retrieves the content from the origin server, serves it to the user, and caches it for future requests.

4. Content Delivery: The content is delivered to the user from the edge server, reducing load on the origin server and enhancing the user experience.

This distributed approach ensures faster load times, reduced bandwidth costs, and improved reliability, even during traffic spikes.

CDN Architecture

A typical CDN architecture consists of the following components:

1. Origin Server: The central repository where the original content is stored, typically the website’s hosting server.

2. Edge Servers: Distributed servers located in various geographical locations. These servers cache content to serve users from the nearest possible location.

3. Points of Presence (PoPs): Physical data centers housing edge servers, strategically placed to maximize coverage and minimize latency.

4. Load Balancer: Distributes incoming traffic across multiple servers to prevent overloading any single server.

5. Content Routing Mechanism: Uses algorithms to direct user requests to the most optimal edge server based on factors like proximity, server health, and cache availability.

6. Analytics and Monitoring Tools: Collect data on performance metrics, user behavior, and system health, providing actionable insights for optimization.

CDN providers typically do not dedicate a single edge server to a specific origin server. Instead, edge servers are shared among multiple origin servers and content providers. This shared infrastructure approach allows CDNs to maximize resource utilization, distribute traffic efficiently, and offer cost-effective solutions to their clients.

However, some enterprise-level CDN services, such as Akamai or AWS CloudFront, may provide dedicated or isolated resources for specific high-demand clients. This could include private caching configurations or dedicated PoPs (Points of Presence) for clients with unique security, compliance, or performance requirements.

This modular architecture enables CDNs to deliver content efficiently, handle high traffic volumes, and provide resilience against server outages or DDoS attacks.

Key Benefits of Using a CDN

• Reduced Latency: Faster load times for end-users.

• Improved Availability: Enhanced uptime and reliability.

• Reduced Server Load: Offloads traffic from the origin server.

• Better Scalability: Handles traffic spikes efficiently.

Push vs. Pull CDNs

CDNs can operate in two primary modes: push and pull. Each mode has its unique use cases, advantages, and trade-offs.

Push CDN

In a push CDN, the content is manually uploaded to the CDN's servers by the content provider. The provider is responsible for ensuring that the latest version of the content is available on the CDN.

How It Works:

1. The website owner uploads content (e.g., images, videos) to the CDN.

2. The CDN stores this content in its servers.

3. When a user requests the content, it is served directly from the CDN’s servers.

Example Use Case: A media company hosting high-quality videos might use a push CDN to pre-upload their videos to ensure users always get the best experience without latency.

Pull CDN

In a pull CDN, content is fetched dynamically from the origin server and cached on the CDN’s edge servers when a user requests it for the first time.

How It Works:

1. A user requests content.

2. If the content is not already cached in the CDN, it is fetched from the origin server.

3. The fetched content is cached for subsequent requests.

Example Use Case: An e-commerce website with frequently updated product images and descriptions can leverage a pull CDN to ensure users always receive the latest content.

Key Differences Between Push and Pull CDNs

Hybrid Approach

Some CDN providers offer a hybrid model, combining the best of both push and pull CDNs. This allows businesses to push critical static assets while relying on pull mechanisms for dynamic content.

Real-World CDN Providers

1. Cloudflare: Primarily operates as a pull CDN, suitable for dynamic websites.

2. Akamai: Offers both push and pull CDN configurations for enterprise-level applications.

3. Amazon CloudFront: Supports a hybrid approach with extensive customization options.

How CDN Sends Analytics Back to the Server

CDNs not only deliver content efficiently but also provide valuable analytics to help content providers monitor performance and user behavior. Here's how it works:

1. Data Collection: The CDN edge servers collect data on metrics such as user location, content type, request times, cache hits and misses, and bandwidth usage.

2. Aggregation: This data is aggregated in real-time or near real-time to provide a comprehensive view of content delivery performance.

3. Transmission to the Origin Server: The CDN transmits this aggregated data back to the origin server or a centralized analytics system, often via APIs or dashboards.

4. Actionable Insights: Content providers can use these insights to optimize delivery strategies, improve cache efficiency, and enhance user experience.

For example, a streaming platform can monitor which regions have the most users experiencing latency, allowing them to strategically deploy additional edge servers in those locations. Analytics also help in identifying popular content, assisting in targeted marketing campaigns.

1. Basic Authentication

Overview

Basic Authentication is a simple way to verify users in REST APIs by sending a username and password in HTTP headers. It’s easy to use but less secure, especially without HTTPS, making it unsuitable for sensitive data or production use.

Here's a quick summary of Basic Authentication in REST APIs:

1. Client Request: The client sends a request to the server with authentication details in the request headers.

2. Encoding: Username and password are combined as username:password and base64-encoded. Note: This is not encryption.

3. Header: The encoded credentials are added to the HTTP request header like this:

Authorization: Basic base64(username:password)

4. Server Check: The server decodes the header, retrieves the username and password, and verifies them.

5. Response: If valid, the server processes the request. If not, it returns a 401 Unauthorized error.

It’s important to use HTTPS when implementing Basic Authentication to encrypt the communication between the client and the server. The credentials are sent in plain text without encryption, making it vulnerable to threats.

Use Cases

• Legacy systems or internal applications.

• Simple APIs with low security concerns.

Pros

• Simple to implement and use.

• Supported by all major HTTP clients and browsers.

Cons

• Credentials are sent with every request, increasing exposure risk.

• Base64 encoding is not encryption so increasing security risk. Needs TLS for security.

• No session management—every request re-sends credentials.

Real-Life Example

• Accessing internal tools or staging environments using a browser pop-up prompt.

2. Token Based Authentication

Overview

Token authentication is more secure than basic authentication since it involves using a unique token generated for each user. JSON Web Tokens (JWT) is a popular token-based authentication method.

JWTs are self-contained and can store user information, reducing the need for constant database queries. This token is sent with each request to authenticate the user. Token authentication is also a good choice for applications requiring frequent authentication, such as single-page or mobile applications.

Since the authentication process does not require user passwords in each request, once a user enters the credentials, receive a unique encrypted token valid for a specified session time.it is more efficient and can handle more concurrent requests.

JWT (JSON Web Token) authentication works in a client-server interaction:

1. User Login

• The client sends login credentials (username and password) to the server.

• The server verifies the credentials.

2. Token Generation

• Upon successful authentication, the server generates a JWT.

• The token contains:

  • Header: Specifies the token type (JWT) and signing algorithm.

  • Payload: Contains user data (e.g., user ID) and claims.

  • Signature: Ensures the token’s integrity using a secret key.

In a serialised form, JWT represents a string in the following format:

[header].[payload].[signature]

Actual JWT token looks like

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MTIzNDU2Nzg5LCJuYW1lIjoiSm9zZXBoIn0.OpOSSw7e485LOP5PrzScxHb7SR6sAOMRckfFwi4rp7o

In deserialised form, JWT will be as per below:

{
  "header": { "alg": "HS256", "typ": "JWT" },
  "payload": { "sub": "1234567890", "name": "John Doe", "admin": true },
  "signature": "signed-data"
}

3. Token Delivery

• The server sends the JWT to the client (often in the response body or a cookie).

4. Token Usage

• The client includes the JWT in the Authorization header (e.g., Bearer <token>) of subsequent requests.

• The token serves as proof of authentication.

Request Header has below:

Authorization: Bearer <token>

5. Token Validation

• The server validates the JWT by:

  • Verifying the signature.

  • Checking the token’s expiration and claims.

6. Access Granted

• If the token is valid, the server processes the request and returns the response.

• If invalid, the server denies access, often returning a 401 Unauthorized status.

Key Points:

• JWTs are stateless, meaning the server doesn’t store session information.

• Expired or invalid tokens require re-authentication.

• Tokens can include additional claims for granular access control.

Use Cases

• Short-lived API sessions.

• Microservices communication.

• Stateless authentication for web and mobile applications.

• Single Sign-On (SSO) scenarios.

Pros

• Self-contained and can carry user claims.

• Stateless: No need to query the database after token issuance.

• Supports token expiration and custom claims.

Cons

• Larger token size compared to others.

• If not properly invalidated, compromised tokens remain valid until expiry.

• Need secure storage to avoid leakage.

Real-Life Example

• Accessing APIs in cloud platforms (e.g., AWS, Azure) and microservice architecture.

3. API Key Authentication

Overview

API keys are unique strings assigned to each client, included in requests to identify the client. They can be passed via headers, query parameters, or request bodies.

1. Obtaining API Key: Clients request an API key from the API provider. This is usually done through a developer portal or some registration process.

2. Including API Key in Requests: Once the API key is obtained, it must be included in each API request.

    GET /api/resource?api_key=123abc
   

3. Server-Side Validation: The API server receives the request and extracts the API key from the specified location (URL parameter, header, etc.). The server checks the validity of the API key by comparing it against a list of authorized keys stored in its database.

4. Authorization Check: Once the API key is validated, the server checks if the associated client or application has the necessary permissions to perform the requested action.

While API keys are a straightforward authentication method, they have some limitations. One of the main concerns is that API keys can be exposed easily if not handled securely, leading to potential security risks. Therefore, following best practices, such as using HTTPS, avoiding exposure of keys in client-side code, and implementing proper critical management practices, is essential. Other authentication methods, like token-based authentication (JWTs), may be preferred for more sensitive applications.

Use Cases

• Public APIs with limited scope access.

• Service-to-service communication.

Pros

• Simple and easy to use.

• Can be restricted by IP or referrer for added security.

Cons

• No built-in user identity (just a key).

• Vulnerable to theft if exposed in public repositories or URLs.

• Hard to revoke individual keys unless tracked explicitly.

Real-Life Example

• APIs for weather, currency conversion, or third-party integration services.

5. OAuth 2.0

Overview

Applications often need to interact with each other on behalf of users. Whether it’s granting access to your Google account for a new app or allowing a third-party service to post to your social media, OAuth 2.0 has become the go-to solution for secure, seamless access delegation.

In this blog, we’ll explore the core concepts of OAuth 2.0, why it’s essential, and how it enables secure interactions between applications.

What is OAuth 2.0?

OAuth 2.0 (Open Authorization 2.0) is an open standard protocol designed to provide secure authorization for applications without exposing user credentials. It allows users to grant limited access to third-party application.

For example, when you sign in to an app using your Google account, OAuth 2.0 facilitates the process, ensuring the app gets access to your profile details without revealing your password.

Key Concepts in OAuth 2.0

OAuth 2.0 operates through several key roles:

• Resource Owner (User): The individual who owns the data and can grant access to it.

• Client (Application): The app requesting access to the user’s data.

• Authorization Server: The server that authenticates the user and grants tokens.

• Resource Server: The server that holds the user’s data and validates tokens for access.

Token-Based Access

OAuth 2.0 uses tokens instead of credentials to grant access. These tokens are temporary and can be tailored for specific permissions, making them more secure and flexible.

There are roughly 2 types of token:

• Access Token: Used to access protected resources.

• Refresh Token: Used to obtain a new access token when the current one expires.

Common OAuth 2.0 Grant Flows

1. Authorization Code Flow (most secure, used for server-side applications):

   • Authorization Request: The client redirects the user to the authorization server to log in and approve access.

   • Authorization Grant: The authorization server provides an authorization code.

   • Token Request: The client exchanges the authorization code for an access token by making a back-channel request.

   • Resource Request: The client uses the access token to access the protected resource.

User request for login and authenticate to get auth code

https://localhost:8080/realms/myrealm/protocol/openid-connect/auth ?response_type=code &client_id=myclient &redirect_uri=http://localhost:3000/callback &scope=openid

After successful authentication, auth server redirect the user to the redirect uri with authorization code

http://localhost:3000/callback?code=AUTHORIZATION_CODE

Once we get authorization code from the url

One can do below curl to get token

curl -X POST "http://localhost:8080/realms/myrealm/protocol/openid-connect/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=authorization_code" -d "client_id=myclient" -d "client_secret=mysecret" -d "redirect_uri=http://localhost:3000/callback" -d "code=AUTHORIZATION_CODE"

Response

{ "access_token": "eyJhbGciOiJSUzI1NiIsInR5c...", "expires_in": 300, "refresh_token": "eyJhbGciOiJIUzI1NiIs...", "id_token": "eyJhbGciOiJSUzI1NiIsInR5c...", "token_type": "Bearer" }

2. Implicit Flow - deprecated (used for single-page applications):

• The client directly receives the access token without an authorization code exchange.

3. Client Credentials Flow (used for machine-to-machine communication):

• The client authenticates itself to the authorization server and directly obtains an access token.

• It doesn’t require any callback url and auth code exchange. Authorization code flow requires callback url. Auth server returns JWT token.

• User will pass clientId and client secret for authentication server.

curl -X POST "https://auth.example.com/oauth/token" -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=myclient" -d "client_secret=mysecret" -d "grant_type=client_credentials"

Response

{ "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI...", "expires_in": 300, "token_type": "Bearer" }

It doesn’t provide refresh token in cc flow.

4. Resource Owner Password Credentials Flow (discouraged due to security concerns):

• The client directly collects the user’s credentials and exchanges them for an access token.

Common OAuth 2.0 Use Cases

• Social Media Integration: Allowing apps to post on behalf of users.

• Cloud Storage Access: Enabling apps to fetch files from services like Google Drive or Dropbox.

• Payment Gateways: Granting access to payment platforms without sharing sensitive information.

Real life : A Step-by-Step Example

Let’s say you want to use a third-party app to analyze your Gmail data:

1. Authorization Request: The app redirects you to Google’s authorization server.

2. User Consent: You log in and grant permission.

3. Token Issuance: Google provides an access token to the app.

4. Data Access: The app uses the token to fetch your Gmail data securely.

Pros

• Securely avoids sharing user credentials with third-party apps.

• Supports Single Sign-On (SSO) for seamless user experience.

• Provides granular access control through token scopes.

• Offers token expiration and refresh for enhanced security.

• Flexible for diverse use cases (e.g., mobile, web, API).

• Widely adopted and integrated with major platforms.

Cons

• Complex implementation increases the risk of errors.

• Token storage and management require careful handling.

• Implicit flow deprecation impacts older implementations.

• Reliance on third-party providers may raise privacy concerns.

Choosing the Right Authentication Method

Conclusion

Each authentication method has its own strengths and trade-offs. For simple use cases, API Keys or Basic Auth may suffice. For stateless, scalable systems, JWT is a strong choice. For delegated access and federated identity, OAuth 2.0 is a robust option. Evaluate your security needs and system architecture before choosing the most appropriate solution.

Have any questions or insights about these methods? Let’s discuss in the comments! 👇

What Are WebSockets?

WebSockets are a communication protocol that allows for full-duplex (two-way) communication between a client (like a web browser) and a server. This means both the client and the server can send and receive messages at any time without waiting for the other to finish.

Why Are WebSockets Used?

WebSockets are increasingly popular because they address the limitations of older protocols like HTTP for real-time communication. Here are the main reasons for their usage:

• Real-Time Data Exchange: Ideal for applications requiring instant updates, such as chat apps, live sports scores, or stock market tracking.

• Reduced Latency: Unlike HTTP, WebSockets keep the connection open, reducing the delay caused by repeatedly opening and closing connections.

• Two-Way Communication: Enables seamless interaction, such as collaborative editing in documents or multiplayer online games.

• Scalable Architecture: Efficient resource use makes WebSockets suitable for large-scale real-time applications.

How Do WebSockets Work?

Here’s a step-by-step explanation of how WebSockets operate:

1. Handshake:

   • The client initiates a connection with an HTTP request with a special header (“Upgrade”).

   • The server responds with status 101, if agreeing to switch the connection from HTTP to WebSocket. It responds with some error code if server doesn’t support webSocket upgrade.

Client request header look like this:

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Version: 13

upgrade field has been set to websocket and connection field has been set to upgrade, which denotes that client is requesting a websocket connection over http. sec-websocket-key is the base64 encoded value that is generated randomly.

Server will receive the request, read the websocket-key and combine with globally unique identifier and do SHA-1 hash of concatenated string. This hash value will be part of field sec-websocket-Accept if it willing to accept the connection.

Server will send the below headers in the form of handshake to the client.

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=

2. Connection Established:

   • Once the handshake is complete, the connection stays open.

3. Real-Time Communication:

   • Both the client and server can send messages to each other anytime.

   • Messages are exchanged using lightweight frames, ensuring efficiency.

4. Connection Closure:

   • Either the client or the server can close the connection when the communication is complete.

WebSocket has a default URI format

ws-URI =  "ws:" "//" host [ ":" port ] path [ "?" query ]
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]

wss denotes a secure web-socket connection with TLS handshake. Separate port will be used on the client and the server side, decided by client and server.

How WebSocket different from HTTP

WebSockets and HTTP may seem similar since they both run over TCP, but their behavior is fundamentally different.

The web-socket protocol is an TCP based protocol. It’s only relationship to HTTP is that its handshake is interpreted by HTTP servers as an upgrade request.

When Is HTTP Preferred Over WebSockets?

While WebSockets excel in real-time communication scenarios, HTTP is still preferred in many situations due to its simplicity and widespread use. Here are some cases where HTTP is a better choice:

• Static Content Delivery:

  • For serving static assets like HTML, CSS, JavaScript, or images, HTTP is more straightforward and efficient.

• Simple Request-Response:

  • For operations like form submissions, API calls, or fetching data where one request yields one response, HTTP is sufficient.

• Short-Lived Connections:

  • For actions that do not require a persistent connection, such as loading a webpage or making occasional API requests.

• Browser and Server Compatibility:

  • HTTP is universally supported and works seamlessly with all browsers, servers, and proxies.

• Security and Caching:

  • HTTP benefits from established security protocols and caching mechanisms, making it ideal for delivering resources efficiently.

• Lower Complexity:

  • HTTP does not require the additional implementation effort needed for managing WebSocket connections and messages.

Conclusion

WebSockets are a game-changer for applications that demand real-time communication. By enabling persistent and efficient two-way communication, WebSockets reduce latency and overhead, making them a go-to choice for modern web and mobile applications. While they might not replace HTTP entirely, they complement it by addressing specific use cases like live updates and interactivity. As real-time applications grow, understanding and leveraging WebSockets can be a significant advantage for developers.

What is Vertical Scaling?

Vertical scaling (also known as scaling up) involves adding more resources to a single machine. This can include:

• Adding more CPU cores

• Increasing RAM

• Upgrading to faster storage (SSDs)

Benefits of Vertical Scaling:

• Simplicity: No need to modify your application architecture.

• Quick to implement: Often requires only hardware upgrades or moving to a larger instance in cloud environments.

• Consistent performance: No need for load balancing or data replication.

Challenges:

• Hardware limits: There’s a ceiling to how much you can scale a single machine.

• Downtime risks: Upgrading a machine often requires downtime, impacting availability.

• Single point of failure: The system remains dependent on one machine.

When to Use Vertical Scaling:

• Applications with monolithic architectures.

• Systems where downtime for upgrades is acceptable.

• When simplicity is a priority and workloads are predictable.

What is Horizontal Scaling?

Horizontal scaling (also known as scaling out) involves adding more machines (nodes) to distribute the load. In cloud environments, this often means deploying more instances of your application.

Benefits of Horizontal Scaling:

• Unlimited scaling potential: You can keep adding nodes as needed.

• High availability: If one node fails, others can continue handling the load.

• Resilience: With proper load balancing, the system can tolerate failures better.

Challenges:

• Complexity: Requires changes to the application architecture to support distributed systems.

• Data consistency: Maintaining data consistency across multiple nodes can be challenging.

• Load balancing: You need effective strategies to distribute traffic across nodes.

When to Use Horizontal Scaling:

• Systems that need to handle large-scale traffic or have unpredictable workloads.

• Applications built using microservices or distributed architectures.

• Scenarios where high availability is a requirement.

A Comparative Table: Horizontal vs Vertical Scaling

Key Considerations When Choosing a Scaling Strategy

• Workload Characteristics:
  If your application has bursty traffic, horizontal scaling can handle spikes better with load balancing.

• Budget Constraints:
  Vertical scaling might be suitable for smaller applications where the cost of multiple nodes is prohibitive.

• Architecture Design:
  Microservices and stateless applications thrive with horizontal scaling, while monolithic apps often require vertical scaling.

• Cloud Provider Features:
  Cloud platforms like AWS, Azure, and GCP offer auto-scaling groups, making horizontal scaling more accessible.

Real-World Examples

• Vertical Scaling:
  A relational database like PostgreSQL on a single server can benefit from vertical scaling by adding more CPU and RAM.

• Horizontal Scaling:
  Web applications using Kubernetes can deploy additional pods to handle increased traffic, making horizontal scaling seamless.

Conclusion

Both horizontal and vertical scaling have their place in system design. While vertical scaling offers simplicity and quick upgrades, horizontal scaling provides better fault tolerance and scalability. As a software engineer, understanding your application’s needs and workload patterns is critical to making the right decision.

Do you have insights on scaling strategies? Share them in the comments!