DEV Community: Biswas Prasana Swain

RAG: The "Open Book" Exam for AI

Biswas Prasana Swain — Thu, 19 Mar 2026 17:56:48 +0000

Building a RAG (Retrieval-Augmented Generation) app is basically giving a genius-level intern (the LLM) a specific handbook so they stop making things up. If you build it with too much "enterprise" bloat, it’ll crawl. If you skimp, it’ll hallucinate.

Here is the lean, mean architecture for a RAG full-stack app.

1. What is a RAG System?

Standard AI (like ChatGPT) works from memory, it's like a student taking a test based only on what they studied months ago. RAG (Retrieval-Augmented Generation) turns that test into an "open book" exam.

Instead of the AI guessing or "hallucinating" when it doesn't know a fact about your specific business or private data, the system first retrieves the relevant page from your digital "book," hands it to the AI, and tells it: "Read this and then answer the question."

2. The Ingestion Pipeline (The Wood Chipper)

Before the user even opens the app, you have to prep your data. This is a one-way street where documents become searchable math.

Load & Chunk: You take your messy PDFs or text files and chop them into bite-sized "chunks." If chunks are too big, they're noisy; too small, they lose context.
Embedding Model: You run those chunks through a model (like OpenAI’s text-embedding-3-small) to turn text into a long string of numbers (vectors). This represents the "meaning" of the text.
Vector Database: You store those numbers in a specialized DB (Pinecone, Weaviate, or Chroma). This is your library where books are organized by "vibe" rather than title.

3. The Backend Orchestrator (The Traffic Cop)

This is usually a Python (FastAPI) or Node.js server. It’s the middleman that manages the "Retrieval" part of RAG.

The Query: User asks, "How do I fix my toaster?"
Vectorization: The backend sends that question to the same embedding model used in the ingestion phase. Now the question is a vector.
The Search: The backend asks the Vector DB: "Find me the 3 chunks of text that are mathematically closest to this question's vector."
The Prompt Stuffing: The backend takes those 3 chunks and "stuffs" them into a prompt template for the LLM.

The Prompt looks like this: > "You are a helpful assistant. Use the following context to answer the question. If it's not in the context, shut up and say you don't know.
Context: [Chunk 1], [Chunk 2], [Chunk 3]
Question: How do I fix my toaster?"

4. The LLM & Frontend (The Face)

The Generation: The LLM (GPT-4, Claude, Llama 3) reads the stuffed prompt and generates a coherent answer based only on the provided context.
The Frontend: A React or Next.js app that displays the chat. It needs to handle "streaming" (where the text appears word-by-word) so the user doesn't think the app crashed while the LLM is thinking.

5. Diagram*

The Tech Stack Comparison

Layer	Recommended (The "Gold Standard")	Fast/Cheap (The "Hobbyist")
Frontend	Next.js + Tailwind	Streamlit
Backend	FastAPI (Python)	LangChain Expression Language (LCEL)
Vector DB	Pinecone or Weaviate	PGVector (Postgres)
LLM	GPT-4o or Claude 3.5 Sonnet	Groq (Llama 3)

Why this works

You aren't "retraining" the AI. You're just giving it a "Search" button. It stops the AI from lying because it has the source material sitting right in front of it. Anything more complex—like multi-agent workflows or graph-based retrieval—is usually overkill until you hit 100k+ documents.

Used AI for Diagram

The Invariance of Software Paradigms

Biswas Prasana Swain — Sun, 15 Feb 2026 11:22:32 +0000

In software engineering, the Invariance of Paradigms is the concept that the fundamental way we build software remains constant, regardless of the specific programming language, library, or framework being used. While syntax (how you write it) changes every few years, the underlying architecture (what you are building) has not fundamentally changed in decades.

1. Frontend: The Component-Based Paradigm

Whether you are using React, Vue, Angular, or even mobile frameworks like SwiftUI, the paradigm is Component-Based Architecture (CBA).

The Idea: You don’t build a "page"; you build a collection of small, independent "blocks."
The Blueprint: A button is a block. A search bar is a block. You snap these blocks together to create a website.
Why it stays the same: This approach ensures that if you fix the "button block," it updates everywhere. The framework is just the glue.

2. Backend: The Service-Oriented Paradigm

Whether the server is written in Node.js, Python (Django), or Java (Spring), the paradigm is Service-Oriented.

The Idea: The backend acts as a "Request-Response" machine.
The Workflow:
Listener: It waits for a specific URL (Route).
Logic: It checks if you’re allowed in (Auth) and does some math or data checking.
Sender: It sends back a standardized package, usually JSON.
Why it stays the same: A server’s job is always to be a middleman between the user and the database.

3. Database: The Structured vs. Unstructured Paradigm

Whether you use PostgreSQL or MongoDB, the paradigm is about Data Modeling.

Relational (SQL): Think of an Excel spreadsheet. Everything has a strict place. If you change a column, you have to change the whole sheet.
Document-Based (NoSQL): Think of a folder full of Word documents. Each document can be slightly different, but they all live in the same folder.
Why it stays the same: We only have two ways to store things: in a strict list or a flexible pile.

4. Comparison Across the Stack

Layer	Common Paradigm	Tool Examples	Core Responsibility
Frontend	Component-Based	React, Vue, Svelte	Presenting data to the human.
Backend	API / Service-First	Express, Django, Go	Business rules and security.
Database	Relational / Document	MySQL, MongoDB	Remembering data forever.

Summary

The "Tech Stack" is a fashion choice; the "Paradigm" is the physics. If you understand that the Frontend is just a tree of components and the Backend is just a series of pipes for data, you can switch from JavaScript to Python in a weekend. Stop chasing the newest library and start mastering the architecture.

Trustworthy References

IBM Technology: Microservices vs. SOA - Explaining the service paradigm.
MDN Web Docs: Component-based architecture - The standard for modern UIs.
Amazon AWS: SQL vs. NoSQL - Defining the two main storage paradigms.
Martin Fowler: Patterns of Enterprise Application Architecture - The "Bible" of why software patterns don't change.

From Monolith to Microservice

Biswas Prasana Swain — Sun, 18 Jan 2026 12:38:59 +0000

A practical guide for people who have heard the word “microservices” too many times and finally want to do something about it.

Most software systems don’t start as microservices. They start as a single application that does everything. User login, payments, emails, reports, admin screens, all tangled together like headphone wires in a pocket. That kind of system is called a monolith. It works fine until it doesn’t. Changes become risky, deployments feel like gambling, and one small bug can take down everything.

Microservices are not magic. They are simply smaller applications that each do one job and communicate with others over the network. The mistake beginners make is trying to convert the entire monolith at once. That is how projects quietly die. The correct move is boring and slow: extract one microservice first.

Step one: understand what you already have

Before touching code, you need to understand your monolith at a business level, not a technical one. Forget frameworks and folders for a moment. Ask a simple question: what does this system actually do for users?

Every monolith contains natural boundaries. User management, billing, notifications, inventory, reporting. These are not technical concepts, they are business capabilities. Your first microservice should represent one clear capability that can survive on its own.

Good candidates share three traits. They have clear inputs and outputs, they change frequently or cause pain when changed, and they do not control the entire database. Authentication, email notifications, and file processing are common first picks because they are easy to isolate and rarely need direct access to everything else.

Step two: define the responsibility, not the technology

A microservice is not “a Spring Boot app” or “a Node service.” That thinking leads to messes. A microservice is a responsibility with rules.

For example, instead of saying “I’ll create a User Service,” say “This service owns user creation, login, and password validation. No other part of the system is allowed to change users directly.” That sentence is more important than any code you will write.

Once responsibility is clear, define how other parts of the system will talk to it. For beginners, HTTP with JSON is the safest choice. One endpoint to create a user, one to fetch user data, one to validate credentials. Simple, boring, reliable.

Step three: copy logic first, then remove it

This part feels wrong but works.

Do not delete code from the monolith immediately. First, copy the relevant logic into a new, separate application. Give it its own repository, its own build process, and its own runtime. At this stage, both systems can do the same thing. That duplication is temporary and acceptable.

Once the new service works on its own, change the monolith so that instead of running the old code, it calls the new service over HTTP. It's called Strangler Fit Pattern. If the behavior stays the same, users never notice. That is the goal. Silence.

Only after this works reliably should you remove the old logic from the monolith. If something breaks, you know exactly where to look, which is a luxury in software.

Step four: separate the data carefully

Beginners often trip over databases. A true microservice owns its data. That means no other service should directly read or write its tables.

For your first microservice, you have two realistic options. The safest is giving it its own database, even if it feels redundant. The second is letting it access the existing database but only specific tables, with a clear plan to move them later. What you must not do is allow multiple services to casually share tables. That recreates the monolith, just with more networking bills.

Data duplication across services is normal. Synchronization is handled through APIs or events, not shared schemas.

Step five: deploy it independently

If your new service cannot be deployed without deploying the monolith, you have not created a microservice. You have created a distributed illusion.

Deploy the service separately, even if it runs on the same server at first. Use a different port, a different process, and a different release cycle. The first time you fix a bug in the microservice without touching the monolith, the whole exercise finally makes sense.

Monitoring and logging matter here. When things go wrong, and they will, you need to know which service failed and why. Centralized logs and basic health checks are enough for a first step. No need to summon Kubernetes gods yet.

Step six: repeat slowly, or stop

After your first success, resist the urge to extract everything. Microservices increase operational complexity. If the pain you removed is smaller than the pain you introduced, stop. One or two well-chosen services already deliver most of the benefit.

Microservices are a tool, not a moral upgrade.

Final thoughts

The hardest part of moving from a monolith to microservices is not coding. It is discipline. Clear boundaries, patience, and the willingness to accept temporary duplication are what make the transition survivable.

If you can extract one service cleanly, you can extract more. If you cannot extract one, extracting ten will not save you.

References

These are trustworthy, widely cited, and written by people who have broken real systems before fixing them.

Martin Fowler's Guide to Microservices: The "bible" of this topic. Fowler explains it clearly without the hype. martinfowler.com

Sam Newman's "Building Microservices" - This book is the gold standard. He coined many of the patterns used today.

AWS on Microservices - Practical, "how-to" guides from the people who host most of the world's services.

What's the solution to CAP theorem in Read Replicas?

Biswas Prasana Swain — Thu, 25 Dec 2025 17:10:23 +0000

CAP theorem says a distributed system can give you Consistency, Availability, or Partition tolerance. Pick any two. Not three. Not “mostly three.” Two. The internet doesn’t care about your optimism.

Now let’s talk about read replicas, because this is where confusion usually starts.

The real-world story

Imagine you run an e-commerce app. Nothing fancy. Users browse products, add to cart, place orders. You have one main database. Life is peaceful. Traffic grows. Database starts sweating. So you do the obvious grown-up thing: add read replicas.

One primary database handles writes. Multiple read replicas handle reads. Suddenly your system feels faster. You feel smarter. LinkedIn post draft opens automatically.

Then a user places an order and immediately refreshes the order page. Surprise: the order is missing. Panic. Bug? Race condition? Database haunted?

No. Welcome to CAP.

What just happened

The write went to the primary database.
The read went to a replica.
Replication is asynchronous, because synchronous replication would make your system slow and fragile.

So for a short time:

Primary has the new order
Replica does not

This is eventual consistency in action. The system chose:

Availability: reads always work
Partition tolerance: network issues won’t kill you
And it sacrificed strong consistency

Read replicas don’t break CAP. They make a choice inside CAP.

So what’s the “solution” in read replicas?

Short answer: there is no single solution. There are trade-offs, and you pick based on business needs, not ego.

Long answer, explained like a normal human.

Option 1: Accept eventual consistency (most common)

This is what companies like Amazon, Netflix, Instagram do for many flows.

You allow stale reads for a short time.
You design UI and flows knowing data may lag.

Examples:

Show “Order placed, updating details…” message
Refresh after a few seconds
Avoid instant read-after-write expectations

This gives you:

High availability
Massive scale
Calm databases

You lose:

Immediate correctness everywhere

This is not laziness. This is engineering maturity.

Option 2: Read-your-writes consistency (smart routing)

For some critical flows, you cheat a little.

If a user just wrote data:

Route their next read to the primary
Or use a session flag like “read from leader for 5 seconds”

This is common in:

Banking dashboards
Order confirmation pages
Profile update screens

Now you get:

Consistency where it matters
Availability everywhere else

Downside:

More complexity
Primary database gets more load

Still worth it.

Option 3: Synchronous replication (rare, expensive)

You force replicas to confirm writes before success.

Now reads are always consistent.

You also get:

Higher latency
Lower availability
System crying during network hiccups

Used only when:

Incorrect data is worse than downtime
Think financial ledgers, not social feeds

Most systems wisely avoid this.

The key realization

Read replicas don’t solve CAP.
They let you choose where you want to bend.

CAP is not a bug to fix.
It’s gravity.

Good systems don’t fight it. They design around it.

The adult takeaway

If you want scale, you accept eventual consistency
If you want correctness, you sacrifice availability
If you want both, you add complex routing logic
If you want all three, you’re selling a course, not building software

Read replicas are not magic.
They’re a very honest trade.

And honesty is rare in distributed systems.

References (the boring but trustworthy kind)

Eric Brewer, “CAP Twelve Years Later: How the Rules Have Changed”
https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/
Martin Kleppmann, Designing Data-Intensive Applications
https://dataintensive.net/
Amazon Dynamo Paper
https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
Google Cloud Docs on Replication and Consistency https://docs.cloud.google.com/datastore/docs/concepts/structuring_for_strong_consistency
Netflix Tech Blog on Eventual Consistency https://netflixtechblog.com/s3mper-consistency-in-the-cloud

From Binary to Brilliance: How Compilers Learned to Write Compilers a.k.a Bootstrapping

Biswas Prasana Swain — Mon, 27 Oct 2025 14:10:22 +0000

Programming languages didn’t pop out of thin air. Humans painfully invented them so we could boss computers around without manually flipping switches like cavemen with PhDs. Here’s the story.

1. Early Days: Speaking Robot Grunt Language

1940s–1950s

Computers only understood machine code (just 0s and 1s).
Then humans realized life shouldn’t be torture, so they invented assembly language (short words like ADD, MOV).
These early languages were written directly in machine code or assembly because what else was available? Exactly nothing.

Languages: Machine Code, Assembly
Implementation: Written in machine code or assembly

2. High-Level Languages: Humans Stop Suffering

1950s–1960s
People said: “Let the computer do the boring work.”

FORTRAN (science & math)
COBOL (business)
LISP (AI, parentheses galore)

Compilers for these languages were mostly written in assembly, because assembly was the only grown-up in the room back then.

Languages: FORTRAN, COBOL, LISP
Implementation: Assembly

3. Compilers Learn to Write Compilers

1970s
Here comes the big brain move.

New languages started being written in the language itself.
This trick is called bootstrapping (more on that soon).

Examples:

C became a superstar. First versions in assembly, then rewritten in C.
Pascal: similar path.

Languages: C, Pascal
Implementation: Started in assembly, later self-hosted (written in themselves)

4. Object-Oriented Show-Off Era

1980s–1990s
Humans start organizing code like “objects,” because organizing life is too hard.

Languages:

C++ (C but angry and complicated)
Java (Write once, debug everywhere)
Python (finally readable)
JavaScript (only language people argue about daily)

Implementation languages:

C++: wrote itself using C++ (after initial C)
Java: implemented in C/C++
Python: implemented mostly in C
JavaScript: implemented in C/C++

5. The Modern Chaos

2000s–Now
Thousands of languages because developers love reinventing the wheel.

Examples:

Rust: implemented in Rust (after initial help from C++)
Go: implemented in C first, later in Go itself
Swift: implemented in C++ and Swift
Kotlin, TypeScript, etc.: often implemented using existing languages like Java or JavaScript

What is Bootstrapping?

This part is actually cool.

Bootstrapping is when a programming language is:

First implemented using an older language (often C or assembly)
Then rewritten using itself
Then its own compiler builds the new compiler

Like a kid growing up and then becoming their own parent’s boss.

Example with C:

Write a tiny C compiler in assembly
Use it to compile a better C compiler written in C
Repeat until humans are free and the compiler is a beast

Why do this?

Self-hosted compilers are easier to maintain
They prove the language is powerful enough to build real systems

Summary Table

Language	First Compiler Implementation	Later/Self Implementation
Assembly	Machine code	Itself (assembly)
FORTRAN, COBOL	Assembly	Assembly/C
C	Assembly	C
C++	C	C++
Java	C/C++	Java (partially)
Python	C	Python/C
Go	C	Go
Rust	C++	Rust

Final Wisdom

Programming language history is basically:

Start from binary pain
Invent slightly less painful systems
Use those systems to build better systems
End up with JavaScript frameworks that change every week anyway

Hope your brain upgraded a bit.

How React Native Talks to Your iPhone and Android… And How It’s Changed

Biswas Prasana Swain — Sun, 07 Sep 2025 19:50:55 +0000

React Native (RN) is a framework that lets developers write apps once and run them on both iOS (iPhones) and Android. Sounds magical, right? But under the hood, there’s a lot of wizardry happening to make this possible.

Let’s break it down, step by step.

1. The Problem RN Solves

Normally, iOS and Android apps speak completely different “languages.”

iOS apps speak Swift or Objective-C
Android apps speak Java or Kotlin

Before React Native, if you wanted your app on both platforms, you basically had to build the same thing twice, like doing your taxes in two different countries at the same time. Painful.

React Native says: “Hey, write in JavaScript—the language web developers already know, and I’ll handle translating it to what the phone understands.”

2. How It Used to Work (The Old Way)

Originally, React Native used something called the bridge. Think of it as a translator sitting between two people who speak completely different languages.

Your code is written in JavaScript (easy for web devs).
The JavaScript runs in its own little world called a JavaScript engine.
Whenever your app needs to display something, like a button, or fetch data, the JS engine sends a message across the bridge to the phone’s native code.
Native code (Swift/Java) handles the actual work, drawing things on screen, accessing the camera, etc.
The results get sent back across the bridge to JS.

Problem: This bridge was slow for complex apps. Imagine ordering food through a translator who walks back and forth carrying messages for every tiny thing. It works, but if you want a smooth 60 FPS experience, it can choke.

3. How It Works Now (The Modern Way)

React Native has evolved. The bridge still exists, but now there’s direct compilation and new architectures:

a) Fabric (New UI Layer)

React Native now talks to the native UI in a smarter, asynchronous way.
Instead of messaging every tiny change one by one, it schedules changes in batches. Think of it like ordering your entire meal at once instead of one forkful at a time.
This makes animations smoother and apps faster.

b) JSI (JavaScript Interface)

Previously, JS lived in a separate world. Now, with JSI, JS can directly call native functions without going through the slow bridge.
It’s like having the translator suddenly become a polyglot who understands both languages perfectly and speaks instantly.

c) TurboModules

In the past, every native feature had to go through the bridge. Now, modules can be lazy-loaded and accessed directly, so they only “wake up” when needed.
Faster startup, less memory usage.

4. What Does This Mean for Developers and Users?

For Developers:

Less frustration with laggy updates between JS and native code.
Can write more complex animations and UI interactions without the dreaded “jank.”
Easier to maintain one codebase that feels native on both platforms.

For Users:

Smoother apps, less battery drain.
Faster launch times.
Animations that don’t make you feel like your phone’s having a seizure.

5. Analogy to Make Your Brain Happy

Old RN: JS is a tourist. Wants a burger. Asks a translator. Translator goes to the kitchen, grabs burger, comes back, repeats for fries, soda, napkins… painfully slow if there’s a lot to order.

New RN: JS is now a multi-lingual chef. Orders can be spoken directly to the kitchen, batches are prepped efficiently, and the meal arrives hot and fast.

6. TL;DR for the Lazy Brain

React Native = write JS once, run everywhere.
Old RN = slow bridge, everything had to walk messages back and forth.
Modern RN = JSI + Fabric + TurboModules = direct communication, smarter scheduling, faster apps.

The result: apps that look and feel native, without the headache of writing twice.

Understanding Core JavaScript Design Patterns

Biswas Prasana Swain — Wed, 27 Aug 2025 18:14:10 +0000

If you’ve been coding in JavaScript for a while, you might have heard about design patterns. But what are they?

Think of design patterns like recipes for solving common problems in programming. Just like a cookie recipe tells you how to mix ingredients to get a perfect cookie, design patterns tell you how to structure your code so it works well, is easy to read, and doesn’t break easily.

Here, we’ll look at four super important patterns: Singleton, Module, Factory, and Observer. Let’s dive in!

1. Singleton Pattern

Idea: Only allow one instance of something to exist.

Analogy: Imagine the principal of a school. There’s only one principal, and everyone talks to that same person if they need help.

Why use it? When you want one object to control something globally, like a game score manager, or a database connection.

JavaScript Example:

const GameManager = (function () {
  let instance; // this will hold the single instance

  function init() {
    let score = 0;

    return {
      increaseScore: function () {
        score++;
        console.log(`Score: ${score}`);
      },
      resetScore: function () {
        score = 0;
        console.log(`Score reset`);
      }
    };
  }

  return {
    getInstance: function () {
      if (!instance) {
        instance = init();
      }
      return instance;
    }
  };
})();

// Usage
const game1 = GameManager.getInstance();
game1.increaseScore(); // Score: 1

const game2 = GameManager.getInstance();
game2.increaseScore(); // Score: 2 (same instance!)

✅ Notice how game1 and game2 are the same instance.

2. Module Pattern

Idea: Keep code organized and hide some parts from the outside world.

Analogy: A backpack. You can keep some things inside (like a pencil case), but only let people see or use what you want them to.

Why use it? To encapsulate code, keeping it neat and preventing accidental changes from outside.

JavaScript Example:

const Calculator = (function () {
  // Private functions
  function add(a, b) {
    return a + b;
  }
  function subtract(a, b) {
    return a - b;
  }

  // Public API
  return {
    sum: add,
    difference: subtract
  };
})();

// Usage
console.log(Calculator.sum(5, 3));        // 8
console.log(Calculator.difference(5, 3)); // 2

✅ Here, add and subtract are hidden inside the module, but we can still use them through Calculator.sum and Calculator.difference.

3. Factory Pattern

Idea: Create objects without specifying the exact class/type.

Analogy: A toy factory. You say "make me a toy," and it gives you a toy depending on your choice like car, doll, or robot, without you building it yourself.

Why use it? When you need lots of similar objects but don’t want to manually create each one.

JavaScript Example:

class Dog {
  speak() {
    console.log("Woof!");
  }
}

class Cat {
  speak() {
    console.log("Meow!");
  }
}

class AnimalFactory {
  static createAnimal(type) {
    if (type === "dog") return new Dog();
    if (type === "cat") return new Cat();
    throw new Error("Unknown animal type");
  }
}

// Usage
const myPet = AnimalFactory.createAnimal("dog");
myPet.speak(); // Woof!

const neighborPet = AnimalFactory.createAnimal("cat");
neighborPet.speak(); // Meow!

✅ You don’t need to know the details of Dog or Cat. The factory does the work.

4. Observer Pattern

Idea: Let objects subscribe to events and react when those events happen.

Analogy: Think of YouTube notifications. You subscribe to a channel, and whenever the creator uploads a new video, you get notified automatically.

Why use it? When one object changes and many others need to know about it.

JavaScript Example:

class Subject {
  constructor() {
    this.observers = [];
  }

  subscribe(observer) {
    this.observers.push(observer);
  }

  unsubscribe(observer) {
    this.observers = this.observers.filter(obs => obs !== observer);
  }

  notify(data) {
    this.observers.forEach(observer => observer.update(data));
  }
}

class Observer {
  constructor(name) {
    this.name = name;
  }
  update(data) {
    console.log(`${this.name} received: ${data}`);
  }
}

// Usage
const news = new Subject();

const alice = new Observer("Alice");
const bob = new Observer("Bob");

news.subscribe(alice);
news.subscribe(bob);

news.notify("New JavaScript tutorial!");  
// Alice received: New JavaScript tutorial!
// Bob received: New JavaScript tutorial!

✅ Any observer subscribed to news automatically gets updates.

Conclusion

Design patterns might sound fancy, but they’re really just smart ways to organize your code. Here’s a quick recap:

Pattern	Idea	Example Use Case
Singleton	Only one instance	Game manager, DB connection
Module	Hide private stuff, expose public API	Calculator, Utilities
Factory	Create objects without knowing details	Toy factory, Animal creator
Observer	Notify objects of changes	Chat apps, YouTube subs

Designing a Ride Hailing Service System (e.g., Uber/Lyft): A Beginner-Friendly Guide

Biswas Prasana Swain — Sat, 26 Jul 2025 20:18:16 +0000

🚖 What Is a Ride Hailing System?

A ride hailing service (like Uber or Lyft) is a platform that connects passengers with drivers through an app or website. Instead of waving for a cab on the street, you can request a ride with a few taps on your phone.

Behind the scenes, this simple experience is powered by a complex distributed system involving real-time location tracking, matching algorithms, payments, notifications, and much more.

🎯 Goal of This Article

To explain, in simple terms, how to design the core components of a ride hailing service, focusing on the most important of system design concepts that make up the real-world solution.

🧱 Core Components of the System

Let's start with a high-level overview of the major pieces involved in such a system:

User App (Passenger)
Driver App
Backend System
Matching Engine
Geolocation & Maps
Trip Management
Notifications
Payments
Database & Storage
Monitoring & Logging

🗺️ Step-by-Step: Designing the Core System

1. 🧍 User Signup & Authentication

What happens?
Both drivers and passengers need to register and log in.

Key Concepts:

Use OAuth 2.0 or token-based authentication.
Store user profiles (name, email, rating, etc.).
Drivers may need additional verification (license, insurance).

🧠 Simple user authentication with token validation (like JWT) covers the majority of access control needs.

2. 📍 Real-Time Location Tracking

What happens?
The app continuously updates the location of drivers and passengers.

Key Concepts:

Use the phone’s GPS and mobile network.
Send location updates every few seconds.
Backend uses WebSockets or MQTT for real-time updates.

🧠 Focus on getting accurate, low-latency GPS updates to the backend efficiently.

3. 🔄 Matching Engine (Dispatch System)

What happens?
The system matches a passenger with the nearest available driver.

How it works:

A passenger sends a ride request.
Backend queries nearby drivers (using location data).
It selects the best one based on distance, rating, etc.
Driver receives the request and accepts or declines.

Tech used:

Geospatial indexing (e.g., using Haversine formula + R-tree or GeoHash)
Priority queues for driver selection.
Use Redis or Elasticsearch for fast geo queries.

🧠 Start by matching based on nearest distance and availability. Add complexity like surge pricing, ratings, or driver preferences later.

4. 🗺️ Maps and Routing

What happens?
The system shows estimated time of arrival (ETA), routes, and pricing.

Key Concepts:

Use APIs like Google Maps or OpenStreetMap for:
- Directions
- Distance
- Estimated time
Helps in fare calculation and trip display.

🧠 Use a third-party API to handle maps and routes instead of building it from scratch.

5. 🚘 Trip Lifecycle Management

States in a Trip:

Ride requested
Driver assigned
Driver en route
Passenger picked up
Trip in progress
Trip completed or cancelled

Key Concepts:

Use finite state machines to track trip states.
Log transitions to ensure traceability.
Handle edge cases like timeouts, cancellations, or no-shows.

🧠 Managing trip states as a finite-state machine helps maintain a predictable flow and debug issues easily.

6. 🔔 Notifications System

What happens?

User gets real-time updates (e.g., “Driver arriving”, “Trip started”).

Key Concepts:

Use push notifications (e.g., Firebase Cloud Messaging).
Use in-app alerts or SMS for redundancy.

🧠 Real-time push notifications with retries cover most of alerting needs.

7. 💳 Payments and Fare Calculation

What happens?

Fare is calculated based on time, distance, surge, etc.
Payment is processed automatically at the end.

Key Concepts:

Integrate with payment gateways like Stripe or PayPal.
Store payment methods securely (use PCI DSS compliance).
Split fare between platform and driver.

🧠 Outsource payments to a trusted provider early on to avoid security risks.

8. 🧠 Database Design

What to store?

Users
Drivers
Trips
Locations
Payments
Ratings

Tech Stack Example:

PostgreSQL or MySQL for relational data (users, trips).
Redis for caching and active drivers.
MongoDB or DynamoDB for flexible trip logs or historical data.

🧠 Use relational DB for critical business logic, and Redis for fast access and geo-indexing.

9. 🧰 Scalability & Microservices

Start with a monolith, then move to microservices for:

Trip management
Notifications
Billing
Driver tracking

Common Tools:

Docker + Kubernetes
Load balancers
Rate limiting
Horizontal scaling

🧠 Only break into microservices when scaling becomes painful. Simplicity wins early.

10. 📊 Monitoring, Logging & Analytics

Track everything:

Driver activity
System health
Failed rides
Payment errors

Tools:

ELK Stack (Elasticsearch, Logstash, Kibana)
Prometheus + Grafana
Sentry or Datadog for error tracking

🧠 Logging key events (like trip start/end, matching failures) gives most of troubleshooting power.

⚙️ Technology Stack (Example)

Layer	Technology
Frontend (Mobile)	React Native / Swift / Kotlin
Backend	Node.js / Python / Go
Database	PostgreSQL, Redis
Maps	Google Maps API
Real-time	WebSockets / MQTT
Payments	Stripe
Deployment	Docker, Kubernetes, AWS/GCP

🧪 Bonus: Handling Edge Cases

No drivers available? Use waitlists or schedule feature.
Driver cancels? Reassign another quickly.
Fake GPS? Add fraud detection logic.
App crashes? Use crash analytics and retry mechanisms.

📌 Summary

Designing a ride hailing system may seem huge, but you can cover most of the use case by focusing on:

Real-time location sharing
Fast, accurate driver-passenger matching
Smooth trip state transitions
Reliable notifications and payments
A simple, observable backend with scalable storage

💡 Final Thought

Every giant system like Uber started as a simple app that just connected drivers and riders. One doesn't need to reinvent everything — use proven tools, start small, focus on reliability, and improve over time.

Designing a URL Shortener

Biswas Prasana Swain — Sat, 05 Jul 2025 12:50:43 +0000

Imagine your friend sends you a super long link to a cat video:

https://www.youtube.com/watch?v=dQw4w9WgXcQ&ab_channel=RickAstleyOfficial&list=PL1234567890ABCDEFGHIJK

That’s ugly, right? What if we could turn it into something like:

https://sho.rt/xyz123

That’s exactly what a URL shortener does — and in this article, you’ll learn how to design such a system, from scratch, even if you’ve never done any system design before.

🌐 What Is a URL Shortener?

A URL shortener is a web service that turns long URLs into short ones. When someone clicks the short link, it redirects them to the original long URL.

Popular examples:

bit.ly
tinyurl.com
t.co (used by Twitter)

🎯 Goal of the System

Design a system that:

Accepts a long URL like https://www.example.com/articles/2025/07/shorten-this-link.
Returns a short URL like sho.rt/abc123.
When someone visits sho.rt/abc123, they’re redirected to the original URL.

🔨 Core Features

Feature	Description
Shorten URL	Accept a long URL and generate a short one
Redirect	Given a short URL, redirect to the original long URL
Analytics (optional)	Count how many times a short URL was clicked
Expiration (optional)	Make some short URLs valid only for a limited time

🧠 Key Design Considerations

Before we build anything, we must think about:

1. Scalability

Can our system handle millions of links and billions of redirects?

2. Availability

Can people always access their links even if something crashes?

3. Speed

Can the system redirect people in milliseconds?

4. Uniqueness

How do we ensure no two links generate the same short code?

🧱 Basic Components

Let’s break down the system into pieces:

[Client] -> [Load Balancer] -> [Application Servers] -> [Database]

Client: The user who wants to shorten or open a link.
Load Balancer: Distributes incoming requests to servers.
Application Server: Handles logic (generate/redirect).
Database: Stores mapping between short and long URLs.

🔢 How to Generate Short URLs

Let’s say we want to shorten this:

https://example.com/my-very-long-article-about-space

We can generate a short URL code in several ways:

Option 1: Hashing

Hash the original URL using a function like SHA-256.
Take the first 6–8 characters of the hash.
Map that to a short code.

✅ Simple
❌ Risk of collision (two URLs might get same short code)

Option 2: Auto-Increment ID + Base62

Store each new URL in the database with a numeric ID (like 123456).
Convert the ID to Base62 (0-9 + a-z + A-Z):

  123456 → "abc123"

✅ Unique, Compact
✅ Easy to reverse
❌ Not random (easy to guess next links)

Option 3: Random String

Generate a random string of 6-8 characters.
Check in DB if it's already taken. If not, save it.

✅ Harder to guess
❌ Can collide, so we need retries

📦 Data Model (Database Schema)

Let’s use a simple table:

Field	Type	Description
short_code	VARCHAR(10)	The generated code, like `abc123`
long_url	TEXT	The original URL
created_at	DATETIME	When the short URL was created
expiry_date	DATETIME	(Optional) Expiration date
click_count	INT	(Optional) Number of times clicked

🚦 Redirect Flow

When someone visits:

https://sho.rt/abc123

Here’s what happens:

User’s browser sends a request to your server with code abc123.
Server looks up the code in the database.
If found, it sends a 301 redirect to the original long URL.
Browser takes the user to the long URL.

🏗️ Putting It Together (Step-by-Step)

1. URL Shortening API

POST /shorten

Request:

{
  "long_url": "https://example.com/article/123"
}

Response:

{
  "short_url": "https://sho.rt/abc123"
}

2. Redirection API

GET /abc123

Action:

Find abc123 in the database.
If found, return a 301 redirect to the long URL.

⚙️ Scaling the System

If the system grows big, here’s how we keep it fast:

1. Caching

Use Redis or Memcached to cache popular short codes in memory.
This avoids hitting the database on every redirect.

2. Sharding

Split the database into multiple machines to handle billions of entries.

3. Rate Limiting

Prevent abuse by limiting how many links a user can create per minute.

4. Load Balancing

Distribute traffic across multiple servers using a load balancer like Nginx or AWS ELB.

🛡️ Security and Edge Cases

Problem	Solution
Malicious URLs (phishing, malware)	Use a URL scanner like Google Safe Browsing
Abuse (spamming)	Rate limit users, add CAPTCHA
Expired links	Add TTL (Time-To-Live) logic
Editable links	Let users log in and manage their links

🏭 Diagram

📊 Optional Features

Analytics Dashboard: Show users how many clicks, locations, devices, etc.
Custom Short Codes: Let users choose their code (e.g., sho.rt/mybrand)
Link Previews: Show metadata when sharing links on social media
QR Codes: Auto-generate QR for each short link

✅ Summary

Concept	Description
Goal	Shorten and redirect URLs
Short Code	Can be generated using hashing, Base62, or random strings
Storage	Store code-to-URL mapping in a database
Redirect	Lookup short code and return 301 redirect
Scaling	Use cache, sharding, and load balancing
Security	Scan for malicious URLs, rate limiting, CAPTCHA
Extra Features	Analytics, custom codes, link expiration

🧠 Final Thought

Even though a URL shortener seems simple on the surface, designing it at scale teaches you many real-world software engineering concepts: databases, caching, hashing, APIs, distributed systems, and security.

Whether you're building for a side project or preparing for a system design interview — mastering the design of a URL shortener is a perfect starting point.

Breaking Down Microservices Architecture

Biswas Prasana Swain — Tue, 27 May 2025 14:15:08 +0000

Imagine you’re organizing a big event. Would you prefer doing everything alone — cooking, decorating, sending invites — or hire a team where each person handles one job? That’s the basic idea behind microservices — a smarter way to build software.

🌐 What Is Microservices Architecture?

Microservices Architecture is a way of building software where each part of the system (called a service) does one thing really well.

Instead of one big “do-it-all” program (called a monolith), we create many small, focused apps that work together. Each microservice handles a specific task, like managing users, showing products, or handling payments.

🏗️ Real-Life Analogy: The Online Store

Let’s say we’re building an online shopping app like Amazon.

In a traditional (monolithic) approach, the app is one giant piece of code that handles:

Logging in users
Showing products
Managing the shopping cart
Placing orders
Processing payments

If anything goes wrong, it might break the whole app. Yikes!

Instead, in a microservices approach, we split this into independent parts:

Microservice	Responsibility
`UserService`	Handles login and signup
`ProductService`	Lists products
`CartService`	Manages the shopping cart
`OrderService`	Places orders
`PaymentService`	Processes payments

Each service is like a specialist in a team.

🧠 How Do They Talk?

These services talk to each other via APIs. Think of APIs like sending messages or making phone calls between departments.

When you click “Buy Now”:

Your app asks the CartService what’s in the cart.
It sends the info to OrderService.
Then PaymentService processes the payment.
Boom — order placed.

🧾 Visual Flowchart

Here's a visual of how everything connects:

🧪 Simple Pseudocode Example

Let’s write basic pseudocode for each microservice to show how it works.

1. 👤 UserService

Handles user login and signup.

class UserService:
    def signup(name, email, password):
        save_user_to_database(name, email, password)
        return "User created"

    def login(email, password):
        if validate_user(email, password):
            return "Token123"  # Like a login session
        else:
            return "Login failed"

2. 🛍️ ProductService

Displays available products.

class ProductService:
    def list_products():
        return ["Shoes", "Laptop", "Headphones"]

    def get_product(product_id):
        return { "id": product_id, "name": "Laptop", "price": 999 }

3. 🛒 CartService

Manages items in a user’s shopping cart.

class CartService:
    carts = {}  # Example: {user_id: [product_ids]}

    def add_to_cart(user_id, product_id):
        carts[user_id].append(product_id)
        return "Product added"

    def view_cart(user_id):
        return carts[user_id]

4. 📦 OrderService

Places orders using cart data.

class OrderService:
    def place_order(user_id, cart_items):
        order_id = save_order(user_id, cart_items)
        return f"Order {order_id} placed"

5. 💳 PaymentService

Handles payment transactions.

class PaymentService:
    def pay(order_id, payment_details):
        if process_payment(payment_details):
            return "Payment successful"
        else:
            return "Payment failed"

🧰 Benefits of Microservices

Benefit	What It Means
Independence	Teams work on services separately
Scalability	Easily scale only the part you need
Reliability	One service can fail, others keep running
Faster Deployment	Release updates quickly and independently

🧱 Comparing to Monolithic Architecture

Monolith	Microservices
One big codebase	Many small services
Shared database	Each service has its own
Hard to scale	Easily scalable
One failure affects all	Isolated failures

🔧 Behind the Scenes: How It Works

Here’s what happens when a customer places an order:

Login → UserService.login()
Browse → ProductService.list_products()
Add to Cart → CartService.add_to_cart()
Checkout → OrderService.place_order()
Payment → PaymentService.pay()

Each step is handled by a different microservice, all coordinated through an API Gateway.

💡 Final Thoughts

Microservices architecture is like running a team of experts, each handling their job efficiently. While it’s more complex behind the scenes, it allows:

Better flexibility
Faster improvements
More stable and secure systems

Whether you're building a shopping site, a mobile app, or a platform — microservices let you build smarter and scale faster.

A Guide to Snapshot Testing React Native Components Using Jest

Biswas Prasana Swain — Sun, 27 Apr 2025 18:44:00 +0000

Imagine you build a beautiful React Native button, and you want to make sure its structure never accidentally changes as your app grows.

Wouldn't it be cool if there was a way to take a "photo" of your component, and later automatically check if it still looks the same?

That's exactly what snapshot testing does!

In this guide, you’ll learn:

What snapshot testing is
Why it’s useful
How to set it up
How to write your first snapshot test
Common mistakes and best practices

Let’s start from scratch. 📸

What is Snapshot Testing?

Think of snapshot testing like taking a picture of your component’s output (its structure and UI code).

Later, every time you run the test again, Jest will:

Take a new snapshot of the component
Compare it to the old snapshot
Tell you if anything has changed

If it changed unexpectedly, Jest will warn you:

"Hey! Your component looks different. Are you sure this is what you want?"

✅ It’s a quick way to detect unexpected changes in how your components are built.

Why Use Snapshot Testing?

Snapshot testing is great for:

UI components like buttons, cards, screens, etc.
Catching accidental UI changes before shipping
Code reviews: you can clearly see what changed in a component
Faster development: no need to manually check everything visually

It’s like having an automated "watchdog" for your app’s structure.

Setting Up Your Environment

If you used npx react-native init to create your app, Jest is already set up for you!

To be sure, check your package.json for:

"scripts": {
  "test": "jest"
},
"devDependencies": {
  "jest": "...",
  "@testing-library/react-native": "...",
  "react-test-renderer": "..."
}

If anything’s missing, install them:

npm install --save-dev jest @testing-library/react-native react-test-renderer

yarn add --dev jest @testing-library/react-native react-test-renderer

Quick Overview: What Tools Are We Using?

Tool	Purpose
Jest	Runs the tests
react-test-renderer	Renders the component to pure JavaScript object (not real device)
@testing-library/react-native	(Optional) Helps simulate user actions

For basic snapshot testing, we mainly use Jest and react-test-renderer.

Writing Your First Snapshot Test

Let's say you have a simple Button component:

Button.js

import React from 'react';
import { TouchableOpacity, Text } from 'react-native';

export default function Button({ title, onPress }) {
  return (
    <TouchableOpacity onPress={onPress} style={{ padding: 10, backgroundColor: 'blue' }}>
      <Text style={{ color: 'white' }}>{title}</Text>
    </TouchableOpacity>
  );
}

Now, let’s write a snapshot test for it!

Button.test.js

import React from 'react';
import renderer from 'react-test-renderer'; // this is react-test-renderer
import Button from './Button';

test('Button renders correctly', () => {
  const tree = renderer.create(<Button title="Click me" onPress={() => {}} />).toJSON();
  expect(tree).toMatchSnapshot();
});

What’s happening here?

renderer.create() creates a fake "rendered" version of your component.
.toJSON() turns it into a plain JavaScript object (representing the structure).
expect(tree).toMatchSnapshot() saves the output into a snapshot file the first time.

The snapshot file looks like this (automatically generated):

Button.test.js.snap

exports[`Button renders correctly 1`] = `
<TouchableOpacity
  onPress={[Function]}
  style={
    Object {
      "backgroundColor": "blue",
      "padding": 10,
    }
  }
>
  <Text
    style={
      Object {
        "color": "white",
      }
    }
  >
    Click me
  </Text>
</TouchableOpacity>
`;

You don't have to create this file manually — Jest handles it!

What Happens When Things Change?

Suppose you accidentally change the button’s color from blue to green in Button.js:

style={{ padding: 10, backgroundColor: 'green' }}

When you run npm test, Jest will tell you:

Snapshot test failed!

It will show you what changed — just like a side-by-side "before and after" comparison.

You’ll have two choices:

If the change was on purpose (you wanted it green), you can update the snapshot.
If the change was a mistake, you can fix the component to match the old snapshot.

How to Update Snapshots

If you intentionally changed your component (and want to accept the new version), just run:

npm test -- -u

yarn test -u

The -u flag tells Jest:

✅ "Update the snapshots with the new output."

When to Use Snapshot Testing (and When Not to)

Good for:

Simple components (Buttons, Cards, Badges)
Reusable UI components that don’t change often
Detecting unexpected UI changes

Not good for:

Components with lots of randomness (e.g., random colors, dynamic IDs)
Highly dynamic components (always different outputs)
Very large and complicated components (snapshots become hard to read)

🔵 Rule of Thumb:

Use snapshot testing for small to medium, stable UI components.

Best Practices for Snapshot Testing

Tip	Why it helps
Keep components small and simple	Easier-to-understand snapshots
Name your tests clearly	Easier to know what failed
Only snapshot important parts	Don’t snapshot whole screens with tons of logic
Regularly review snapshots manually	Catch unwanted changes before accepting updates
Combine with other types of tests (like behavior tests)	Don’t rely only on snapshots

Common Beginner Mistakes

Mistake	Solution
Blindly updating snapshots (`-u`) without checking	Always check the diff first before accepting
Taking snapshots of huge, complex screens	Break down into smaller components
Snapshotting things that always change (e.g., timestamps, random IDs)	Avoid snapshotting unstable output

Conclusion

Snapshot testing is a simple but powerful tool to catch unexpected UI changes in your React Native app.

With just a few lines of code, you can:

Capture your component's structure
Be alerted when something changes
Review and update your app's design with confidence

Remember:

Snapshots are helpers, not absolute proofs.
Always review snapshot changes carefully.
Start small and practice often!

Quick Recap

You learned	Key Point
What snapshot testing is	Taking a "photo" of your component's structure
How to set it up	Jest + react-test-renderer
How to write a snapshot test	`expect(tree).toMatchSnapshot()`
How to handle changes	Review, then `npm test -- -u` if intentional
Best practices	Keep components small, review snapshots

A Comprehensive Guide to Redux and Redux-Saga for Beginners

Biswas Prasana Swain — Fri, 04 Apr 2025 18:26:47 +0000

State management is a crucial aspect of modern frontend development, especially when working with large-scale applications. Redux and Redux-Saga are two popular libraries in the React ecosystem that help manage and handle application state efficiently.

In this article, we'll explore Redux and Redux-Saga from the ground up, assuming no prior knowledge. By the end, you'll understand:

What Redux is and why it is needed
The core principles of Redux
How to implement Redux in a React application
What Redux-Saga is and why it's useful
How to handle side effects with Redux-Saga

Let’s get started!

🟢 What is Redux?

Redux is a predictable state management library that helps manage the global state of a React application. It allows you to store, update, and retrieve data efficiently while ensuring a single source of truth for your app's state.

🔥 Why Use Redux?

Centralized State – Stores application data in a single location (Redux store).
Predictability – The state is immutable and only updated in a controlled manner.
Debugging & Testing – With tools like Redux DevTools, debugging becomes easier.
Scalability – Helps maintain state in large applications.

🟢 Core Concepts of Redux

Redux follows a unidirectional data flow with three key components:

Store – The central place where the application state is stored.
Actions – JavaScript objects that describe what should happen in the app.
Reducers – Pure functions that take the current state and an action, then return a new state.

📌 Understanding Redux Flow:

A component dispatches an action.
The reducer processes the action and returns a new state.
The store updates and provides the new state to the React components.

🟢 Setting Up Redux in React

🔧 Installing Redux and React-Redux

To use Redux in a React project, install the necessary libraries:

npm install redux react-redux

🔹 Step 1: Define Actions

Actions describe what happens in your app. Each action has a type and an optional payload:

// actions.js
export const INCREMENT = "INCREMENT";

export const increment = () => ({
  type: INCREMENT,
});

🔹 Step 2: Create a Reducer

Reducers handle state changes based on the dispatched action:

// reducer.js
import { INCREMENT } from "./actions";

const initialState = { count: 0 };

const counterReducer = (state = initialState, action) => {
  switch (action.type) {
    case INCREMENT:
      return { ...state, count: state.count + 1 };
    default:
      return state;
  }
};

export default counterReducer;

🔹 Step 3: Create a Redux Store

The store holds the entire application state.

// store.js
import { createStore } from "redux";
import counterReducer from "./reducer";

const store = createStore(counterReducer);

export default store;

🔹 Step 4: Connect Redux to React

Use the Provider component from react-redux to make the Redux store accessible in your React app.

// index.js
import React from "react";
import ReactDOM from "react-dom";
import { Provider } from "react-redux";
import store from "./store";
import App from "./App";

ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById("root")
);

🔹 Step 5: Access Redux State in Components

Use useSelector to read state and useDispatch to dispatch actions.

// Counter.js
import React from "react";
import { useSelector, useDispatch } from "react-redux";
import { increment } from "./actions";

const Counter = () => {
  const count = useSelector((state) => state.count);
  const dispatch = useDispatch();

  return (
    <div>
      <h2>Count: {count}</h2>
      <button onClick={() => dispatch(increment())}>Increment</button>
    </div>
  );
};

export default Counter;

✅ Now, when you click the button, the counter updates using Redux!

🟢 What is Redux-Saga?

Redux by itself is great for managing application state, but when dealing with asynchronous operations like API calls, it requires middleware. This is where Redux-Saga comes in.

🔥 Why Use Redux-Saga?

Handles side effects elegantly – Unlike Redux Thunk, Sagas use generator functions, making asynchronous flows more manageable.
Manages complex workflows – Helps orchestrate multiple async tasks.
Better control over API calls – You can cancel, debounce, or retry actions.

🟢 Setting Up Redux-Saga

🔧 Install Redux-Saga

npm install redux-saga

🔹 Step 1: Create a Saga Function

A saga listens for dispatched actions and performs side effects.

// sagas.js
import { takeEvery, put, delay } from "redux-saga/effects";
import { INCREMENT } from "./actions";

function* incrementAsync() {
  yield delay(1000); // Simulates API call delay
  yield put({ type: INCREMENT });
}

export function* watchIncrement() {
  yield takeEvery("INCREMENT_ASYNC", incrementAsync);
}

🔹 Step 2: Connect Redux-Saga to Redux Store

Modify the store to use redux-saga middleware.

// store.js
import { createStore, applyMiddleware } from "redux";
import createSagaMiddleware from "redux-saga";
import counterReducer from "./reducer";
import { watchIncrement } from "./sagas";

const sagaMiddleware = createSagaMiddleware();
const store = createStore(counterReducer, applyMiddleware(sagaMiddleware));

sagaMiddleware.run(watchIncrement);

export default store;

🔹 Step 3: Dispatch Async Actions in Components

Modify the component to trigger the async action.

// Counter.js
import React from "react";
import { useSelector, useDispatch } from "react-redux";

const Counter = () => {
  const count = useSelector((state) => state.count);
  const dispatch = useDispatch();

  return (
    <div>
      <h2>Count: {count}</h2>
      <button onClick={() => dispatch({ type: "INCREMENT_ASYNC" })}>
        Increment (Async)
      </button>
    </div>
  );
};

export default Counter;

Now, when you click the button, Redux-Saga will handle the increment after a delay of 1 second.

🟢 Comparing Redux-Saga and Redux Thunk

Feature	Redux-Saga	Redux Thunk
Uses	Generator functions	Promises/async-await
Best for	Complex async flows	Simple async calls
Middleware	`redux-saga`	`redux-thunk`
Control	Can cancel, debounce, retry	Basic control over API calls

For simple applications, Redux Thunk is sufficient, but for large-scale applications, Redux-Saga provides better control over side effects.

🟢 Conclusion

Redux simplifies state management, and Redux-Saga handles asynchronous operations efficiently. Together, they provide a powerful and scalable solution for managing complex applications.

✅ Key Takeaways:

Redux manages application state centrally.
Actions describe what happens, Reducers update the state, and the Store holds everything.
Redux-Saga handles side effects using generator functions.
Sagas listen for actions, perform async tasks, and dispatch new actions.

If you’re working on a large-scale React application, Redux with Redux-Saga is an excellent choice!