Kunal Chaudhari
Open to work Let's talk

(Hospitality) 2025 · Webbrains Technologies

Hospitality Booking CMS

Popular pages served instantly, and bad traffic kept out.

The engine behind a hotel booking site: popular pages served instantly from memory, and protection that keeps bots and bad requests out — so real guests always get through.

Role
Full Stack Developer
Focus
Caching, hardening, query cost
Status
Delivered, 2025

(01) In numbers

  • 1Database read per cache window

    A repeated read is answered by Redis, not by Mongo

  • 4Layers of hardening

    Helmet, rate limiting, sanitisation, signature checks

  • 2025Shipped

    Built, hardened and handed over

(02) Under the hood

Most of these requests should never reach the database

  1. 01 · REQUEST

    Booking or listing

    The busiest endpoints on a booking platform are reads, and the same read arrives many times over.

  2. 02 · SHIELD

    Helmet and rate limits

    Headers set, request rates bounded. The cheapest request to serve is the one that is turned away early.

  3. 03 · SANITISE

    Input cleaned

    Whatever arrives is sanitised and validated before it is allowed to mean anything downstream.

  4. 04 · CACHE

    Redis lookup

    If the answer is already known, the request stops here. A repeated read never reaches the database twice.

  5. 05 · SERVICE

    On a miss

    Only a miss continues. The service does the work once, and the result is written back to the cache on the way out.

  6. 06 · DATA

    MongoDB, indexed

    Compound indexes behind the queries a miss lands on, so the slow path is not actually slow either.

  7. 07 · MONEY

    Signature verification

    Anything that takes a payment verifies the signature before it believes the callback.

(03) The story

01 — The Problem

The busiest endpoints were the most repetitive ones

Content and listing endpoints get asked the same question constantly and change comparatively rarely. Served straight from the database, every one of those identical requests is a query somebody pays for — and those same public routes are the ones that get probed.

  • High-traffic read endpoints answering the same question repeatedly.
  • Public routes that take input, and routes that take money.
  • Queries that had to stay fast on a miss as well as on a hit.

02 — What I Built

Redis in front, hardening around

A caching layer sits ahead of the high-traffic content endpoints, and the routes behind it were hardened: Helmet, rate limiting, input sanitisation, and signature verification on anything involving a payment. Compound indexes cover the queries a miss falls through to.

  • A Redis caching layer in front of the high-traffic content endpoints.
  • Helmet and rate limiting across the public surface.
  • Input sanitisation and validation ahead of every handler.
  • Signature verification on payment callbacks, and compound indexes behind the aggregations.

03 — What Changed

The repeated read stops being a query

A read that has already been answered is answered again from memory. The database sees the misses — and the misses have an index waiting for them.

  • Repeated reads are served without touching MongoDB.
  • The public surface is bounded rather than open-ended.
  • A payment callback is believed only once its signature has been.

(04) Architecture

A cache, and the hardening around it

  1. 01

    Clients

    The booking front end and the public content surface.

  2. 02

    Edge

    Nginx with SSL, PM2 keeping the service up.

  3. 03

    Hardening

    Helmet, rate limiting and input sanitisation across the public routes.

  4. 04

    Cache

    Redis in front of the high-traffic content endpoints.

  5. 05

    API

    Express modules for listings, availability, bookings and payment.

  6. 06

    Data

    Mongoose models with compound indexes behind the aggregations.

(05) Decisions

Why it is built this way

  1. (01)

    Cache the question, not the page

    The caching layer sits at the endpoint, keyed by what was asked. That keeps it honest about what it is holding, and cheap to invalidate when the underlying content changes.

  2. (02)

    Harden the public surface first

    The routes carrying the most traffic are also the routes most exposed to the internet. Helmet, rate limiting and sanitisation go there before they go anywhere else.

  3. (03)

    Verify anything that moves money

    A payment callback is an unauthenticated request from the internet until its signature has been checked against the secret. So it gets checked.

(06) Built with

What it runs on

Fast because most requests stop early, and safe because the rest are checked.

For the technically curiousA Redis caching layer and hardened APIs on the endpoints carrying the traffic. A booking platform whose busiest endpoints were read endpoints — the same content, asked for again and again. A Redis caching layer now sits in front of them, so a repeated read never reaches the database twice, and the public routes behind it were hardened to match.

Node.jsExpressMongoDBMongooseRedisReactHelmetRate LimitingSignature VerificationDockerNginxPM2

Next case study Data & ML NYC Taxi Trip Duration Six prediction models, tested side by side, to estimate how long a taxi ride takes.
Build something like this All case studies