DEV Community: Danish Raza

Docker for MERN Developers: How I Actually Learned It (and Why It Clicked)

Danish Raza — Sun, 12 Jul 2026 11:27:00 +0000

For the longest time, Docker was that thing on my resume-worthy-tools list that I hadn't really earned. I knew the buzzwords — containers, images, docker-compose — but I didn't know Docker the way you know a tool you've actually shipped something with.

That changed while building BotForge, my multi-tenant no-code AI chatbot builder. Here's how the pieces fell into place, and how Docker now fits naturally into my MERN workflow.

The "it works on my machine" wall

BotForge isn't a single service. It's a MERN app with a Node/Express API, MongoDB, a four-tier RAG pipeline hitting Gemini embeddings, and integrations with WhatsApp and Telegram. Running all of that locally meant juggling environment variables, Node versions, and Mongo instances — and every time I handed the project to my teammate or tried deploying to Render, something that worked perfectly on my laptop broke somewhere else.

That's the exact pain Docker exists to solve, and once I framed it that way, the concept stopped being abstract.

The mental model that made it click

Forget the textbook definitions for a second. Here's the analogy that actually worked for me:

Image = a recipe. It lists every ingredient and step needed to make your app run — Node version, dependencies, source code, start command.
Container = the dish made from that recipe. You can make the same dish a hundred times, on a hundred different stoves, and it comes out identical every time.
Dockerfile = the recipe card itself, written in a language Docker understands.

Once containers stopped feeling like "mini virtual machines" and started feeling like "a guaranteed-identical environment," everything else — layers, volumes, networking — became details I could look up as needed instead of concepts I had to memorize upfront.

How I actually learned it (step by step)

Dockerized one thing first — not the whole BotForge stack, just the Express API. A minimal Dockerfile, one EXPOSE, one CMD. Got it running with docker run.
Understood images vs. containers hands-on by running the same image twice and watching two independent containers spin up.
Introduced docker-compose once I needed Mongo alongside the API — this is where Docker started feeling useful instead of academic, because one docker-compose up replaced a page of setup instructions.
Broke things on purpose — killed containers mid-run, misconfigured ports, forgot .dockerignore and watched node_modules bloat my image. Debugging is where the concepts actually stick.
Recently, I turned this whole progression into an interactive Docker learning page for other MERN devs walking the same path — writing it out taught me as much as building the thing did.

Where Docker actually fits in a MERN stack

This is the part a lot of tutorials skip: Docker isn't one container, it's usually several, talking to each other.

A typical MERN docker-compose.yml looks roughly like this:

services:
  api:
    build: ./server
    ports:
      - "5000:5000"
    environment:
      - MONGO_URI=mongodb://mongo:27017/botforge
    depends_on:
      - mongo

  client:
    build: ./client
    ports:
      - "3000:3000"

  mongo:
    image: mongo:7
    volumes:
      - mongo-data:/data/db

volumes:
  mongo-data:

Each service — React frontend, Express API, MongoDB — gets its own container, its own isolated environment, and they talk to each other over Docker's internal network using service names instead of localhost. For BotForge specifically, this meant my RAG pipeline, the API layer, and the database could all be versioned and deployed together, and the exact same setup that ran on my machine ran identically on Render.

The payoff

The real win wasn't learning Docker commands — it was what it removed: no more "install Node 18.x, then Mongo, then set these seven env vars" onboarding docs. Just docker-compose up. For a multi-tenant app like BotForge, where consistency across environments actually matters, that's not a nice-to-have, it's the difference between a demo and something deployable.

If you're a MERN dev starting today

Don't start with docker-compose. Don't start with Kubernetes (please don't). Start by Dockerizing one Express route. Watch it run identically twice. Then add Mongo. Then add your frontend. The stack builds itself once the first container clicks — and it will click faster than the docs make it seem.

Building for Bursty Traffic: Queues and Real-Time Design for a World Cup App July 11, 2026

Danish Raza — Sat, 11 Jul 2026 10:33:45 +0000

Sports traffic is a brutal test case for system design. Nothing happens for 89 minutes, then a goal fires and every connected client wants an update in the same second. I hit this directly building a World Cup 2026 companion app — live scores, match analysis, notifications — using Next.js, Socket.io, and Redis-backed job queues (BullMQ).

This isn't a system handling millions of concurrent users. But the design questions that traffic pattern forces on you are the same ones you'd face at much larger scale — you just get more room to experiment before it actually breaks. Here's what I learned about async processing and real-time delivery.

1. Async-first beats synchronous-and-hope

Handling bursty traffic synchronously — API request comes in, app does the work, app responds — falls over exactly when it matters most, because your spikes are correlated with the thing your users actually care about. A missed goal notification during the one minute it mattered is worse than no feature at all.

So anything that wasn't required to happen in the request-response cycle got pushed into a queue: fetching and processing match events, fanning out notifications, running post-match analysis. The web server's job became "accept the request fast and hand off the work," not "do the work." Redis-backed queues gave me retry logic and backpressure almost for free — if a burst of events comes in faster than workers can process them, they queue instead of timing out or crashing the server.

The tradeoff is real: async systems are harder to reason about, harder to debug (where did this job go?), and you now have eventual consistency to think about instead of "it just happened." But for anything bursty, that tradeoff is almost always worth it over a synchronous system that's simpler right up until the one moment it isn't.

2. Real-time doesn't mean "broadcast to everyone"

Socket.io makes it dangerously easy to broadcast every update to every connected client. That works fine in a demo. It does not work once you have thousands of people watching different matches, because now every client's browser is filtering out most of the messages it receives just to find the one it cares about.

The fix was scoping connections into rooms — one per match — so a client only receives events for what it's actually watching. This is an obvious idea in hindsight, but it's the kind of thing that's easy to skip when you're focused on "does real-time work at all," and only becomes a problem once your Socket.io server is doing meaningfully more work than it needs to per connected client.

The general principle: real-time infrastructure scales by what you don't send, not just by how fast you send it. Scoping and targeting your broadcasts is usually a bigger scalability lever than optimizing the transport itself.

3. Your real bottleneck is probably someone else's API

The app leans on third-party services for live data, AI-powered analysis (Gemini), and billing (Stripe) — each with its own rate limits and failure modes that don't show up until traffic actually spikes. A burst of match events can mean a burst of downstream calls to generate analysis or trigger notifications, and none of those upstream services promise to absorb that burst gracefully just because your own queue can.

That pushed rate-limiting and backoff logic down into the worker layer itself, not just the request layer — workers pulling jobs off the queue needed to respect external rate limits independently of how fast jobs were arriving. The queue smooths out your bursts; it doesn't automatically smooth out the burst you're about to hand to someone else's API.

The lesson: when you sketch your architecture diagram, the boxes representing external APIs deserve as much design attention as the boxes you control. Queueing your own work is necessary but not sufficient — you have to think about what your workers do when they hit someone else's limits too.

4. Cheap infrastructure, disciplined architecture

This system runs on free/low-tier hosting, not a fleet of load-balanced servers — because that's the reality of building as a student. That constraint was useful. It forced decisions that scale regardless of the infrastructure underneath: stateless services that don't care which instance handles a request, background work that lives in a queue instead of memory, and real-time connections scoped tightly enough that they don't waste bandwidth they don't need.

The uncomfortable truth is that most "scalability" problems people reach for infrastructure to solve are actually architecture problems. A tightly-coupled, synchronous system doesn't get more scalable by throwing more servers at it — it just gets more expensive in the same shape. Fixing the shape first, on cheap infrastructure, means that if I do need to scale the infrastructure later, I'm scaling something already designed to be scaled.

Takeaways

Push bursty, non-critical-path work into queues — synchronous systems fail exactly when traffic spikes matter most.
Scope real-time broadcasts — sending less is usually a bigger lever than sending faster.
Rate-limit at the worker layer, not just the request layer — your queue smooths your own bursts, not the ones you hand downstream.
Fix the architecture before reaching for infrastructure — cheap hosting with disciplined design scales further than you'd expect.

None of this required expensive infrastructure or massive traffic to learn — it just required paying attention to why a design choice mattered, not just whether it worked in the demo. That's the part that transfers, regardless of what you're building next.

I'm a final-year CS student building AI-integrated MERN stack applications. Part one of this series covers the multi-tenant RAG side of things, built for a very different kind of load — drop a comment if you've hit similar queueing or real-time tradeoffs.

Designing a Multi-Tenant RAG Pipeline: Lessons From Building an AI Chatbot Platform

Danish Raza — Fri, 10 Jul 2026 10:26:28 +0000

Most "scalable system design" articles describe theoretical systems handling millions of users that neither the writer nor the reader will ever actually build. This isn't that. This is what I actually learned architecting a multi-tenant AI chatbot builder — the kind of system where dozens of businesses share one backend, each with their own bots, knowledge bases, and messaging integrations — on a student budget, with free-tier infrastructure.

The system doesn't serve millions of requests a day. But the design questions you hit at 100 requests a day are the same ones you hit at 100,000 — you just get more room to be wrong and fix it. Here's what I learned about retrieval-augmented generation (RAG) and multi-tenancy before I actually had scale to worry about.

1. Design for tenants before you design for traffic

The chatbot builder needed to support many businesses (tenants), each with their own bots, knowledge bases, WhatsApp/Telegram connections, and usage limits — all on one shared backend.

The tempting shortcut is to bolt tenancy on later: one database, a userId field sprinkled into every collection, and hope nothing leaks. I went the other way and treated tenant isolation as a first-class part of the schema from day one — every document that mattered (bots, conversations, knowledge base chunks, subscription state) carried a tenant identifier that every query had to pass through, no exceptions.

The tradeoff: it's slower to build features early on, because you can't cut corners on "whose data is this." The payoff: when you add a new feature later, you're not doing an emergency audit of every collection to figure out where tenant data might be leaking into another tenant's view. Isolation-by-default is one of those decisions that's nearly free at the start and extremely expensive to retrofit.

2. Not every request needs the same amount of work

The chatbot's core feature is retrieval-augmented generation: a user asks a question, the system searches a knowledge base, and an LLM answers using the retrieved context. The naive version of this does one thing — embed the query, run a vector search, stuff results into a prompt — for every single request, regardless of how the question is phrased or what's actually being asked.

That's wasteful. A one-word follow-up question and a complex multi-part query don't need the same retrieval effort, but they'll cost the same if you treat them identically.

I ended up building the retrieval pipeline in tiers — cheaper, faster paths handle requests that don't need deep retrieval, and progressively heavier tiers only kick in when the query actually warrants it. In production this pipeline consistently retrieves relevant context with around 90% accuracy at roughly 780ms average latency — good enough to feel responsive in a chat interface, without paying full retrieval cost on every message.

The general lesson isn't "build a four-tier pipeline." It's: look for the cases where you're doing expensive work uniformly across requests that don't uniformly need it. That gap is usually where your easiest scalability wins live, and it's almost always cheaper than reaching for more infrastructure.

3. Your real bottleneck is probably someone else's API

The platform leans heavily on third-party APIs — Gemini for embeddings and generation, WhatsApp's Cloud API and Telegram's Bot API for messaging. These have their own rate limits, latency, and failure modes that you don't control, and at small scale it's easy to forget they're there until a burst of traffic hits one at once.

Multi-tenant WhatsApp integration made this concrete: each business brings its own WhatsApp number via Meta's Embedded Signup flow, but the app still has to be a good citizen of Meta's platform-wide rate limits across every tenant combined, not just per-tenant. That means rate limiting and backoff logic had to be designed at the application layer, not assumed away because "each tenant has their own number."

The lesson: when you sketch your architecture diagram, the boxes representing external APIs deserve as much design attention as the boxes you control. They will rate-limit you, they will have outages, and they will not always fail gracefully. Plan for it before you need to.

4. Cheap infrastructure, disciplined architecture

This system runs on free/low-tier hosting (Render), not a fleet of load-balanced servers — because that's the reality of building as a student. That constraint was useful. It forced decisions that scale regardless of the infrastructure underneath them: strict tenant isolation, tiered retrieval instead of brute-force retrieval, and rate-limit-aware integrations instead of naive ones.

The uncomfortable truth is that most "scalability" problems people reach for infrastructure to solve are actually architecture problems. Fixing the shape of the system first, on cheap infrastructure, means that if I do need to scale the infrastructure later, I'm scaling something already designed to be scaled — not retrofitting scalability onto something that was never built for it.

Takeaways

Isolate tenants at the schema level from day one — retrofitting isolation later means auditing everything you've already built.
Don't do uniform work for non-uniform requests — tiering retrieval effort to what a query actually needs is often a bigger win than adding infrastructure.
Design for the external APIs you don't control — they're often the actual bottleneck, not your own code.
Fix the architecture before reaching for infrastructure — cheap hosting with disciplined design scales further than you'd expect.

I'm a final-year CS student building AI-integrated MERN stack applications. Part two of this series covers the async and real-time side of things, built for a very different kind of load — drop a comment if you've hit similar RAG or multi-tenancy tradeoffs.

Building a Four-Tier Parallel RAG Pipeline with Gemini

Danish Raza — Tue, 07 Jul 2026 12:39:27 +0000

The Problem

When building BotForge, our AI no-code chatbot platform, we needed a retrieval system that could handle messy, real-world user queries — typos, partial phrases, semantically similar-but-differently-worded questions.

A naive vector search alone wasn't good enough. It's powerful but brittle to out-of-vocabulary terms and exact keyword lookups.

The Solution: Four-Tier Parallel Retrieval

We ran four retrieval strategies simultaneously using Promise.all\, then merged results with a weighted scoring function.

\javascript const [semanticResults, textResults, regexResults, fuzzyResults] = await Promise.all([ semanticSearch(query, embeddings), // weight 1.8x mongoFullTextSearch(query), // weight 1.5x regexKeywordSearch(query), // weight 1.0x fuzzyPerWordMatch(query), // weight 0.6x ]) \\

Tier 1: Semantic Search (1.8× weight)

Using Gemini gemini-embedding-2\ to produce 3072-dimensional vectors, we compute cosine similarity against stored document embeddings. This catches meaning — "how do I reset my login?" matches "account recovery options" even with no shared words.

Tier 2: MongoDB Full-Text Search (1.5× weight)

A native MongoDB Atlas text index for fast, exact keyword hits. Great for technical terms, product names, and precise phrases.

Tier 3: Regex Keyword Matching (1.0× weight)

Each significant word in the query is compiled to a case-insensitive regex. Catches partial matches and hyphenated variants.

Tier 4: Fuzzy Per-Word Matching (0.6× weight)

Levenshtein distance matching per query word — handles typos and misspellings like "configuraton" → "configuration".

Weighted Score Merging

Each result carries a base score from its retrieval strategy. We deduplicate by chunk ID, sum scores across strategies, and sort descending:

\javascript function mergeResults(tiers, weights) { const scoreMap = new Map() tiers.forEach((results, i) => { results.forEach(({ id, score, chunk }) => { const weighted = score * weights[i] scoreMap.set(id, { chunk, total: (scoreMap.get(id)?.total || 0) + weighted, }) }) }) return [...scoreMap.values()].sort((a, b) => b.total - a.total).slice(0, 5) } \\

Results

~90% retrieval accuracy on held-out test queries
~780ms median latency end-to-end (including embedding generation)
Robust to typos, paraphrasing, and domain-specific terminology

The parallel architecture was the key insight — running all four strategies concurrently keeps latency close to the slowest individual strategy (semantic search) rather than multiplying it.

What I'd Do Differently

Cache embeddings for frequently asked questions
Add a re-ranking step (cross-encoder) for the top 10 candidates
Explore ColBERT-style late interaction for finer-grained scoring