Skip to content

fig. Ptravel & tourism · 2024

Travel Kampany A case study by Mayank Panchal

Travel & Tourism

A dynamic travel platform with itinerary builders, destination showcases, and secure payment gateways.

Visit live All projects
Travel Kampany - Travel & Tourism: homepage screenshot of the travel & tourism platform built by Mayank Panchal
Role
Full-Stack Developer
Client
Travel Kampany
Year
2024
Category
Travel & Tourism

Overview

Travel Kampany set out to make custom trip planning feel as effortless as booking a flight. We architected a dynamic platform around a flexible itinerary builder, destination showcases that double as marketing pages, and a hardened payment flow that supports multiple gateways. The stack is built for speed and scale - destinations and packages are managed entirely from a custom admin.

Highlights

  1. 01

    Custom itinerary builder with drag-to-reorder days

  2. 02

    Secure multi-gateway payments with retry logic

  3. 03

    Destination CMS with SEO-friendly URLs

  4. 04

    Sub-second navigation via aggressive caching

fig. P.2system design

How it’s built.

A PHP application renders destinations and the itinerary builder behind an aggressive page cache, while a Node.js service owns the slow, failure-prone integrations - and a payment router keeps checkout alive when one gateway is not.

fig. P.2 — architecture · travel kampany
Cached PHP storefront · Node integration service
01 · Client02 · Edge03 · Application04 · Integrations05 · Data06 · PlatformTravellerbrowse · build · payAdminpackages · pagesPage cacheHTML · assetsPHP apppages · itineraryPayment routerretry · failoverNode.js serviceAPI integrationsGateway AprimaryGateway BfallbackPartner APIsavailability · ratesDatabasepackages · bookingsGitversioned theme + appWeb serverPHP-FPM · Node
  • Client
  • Edge / proxy
  • Service
  • Third party
  • Database
  • Platform
  • async

Flow · Browse · edge hit

Destination pages never wait on PHP.

01 / 03

Design decisions

  1. 01Where payments live

    A single payment router in front of multiple gateways.

    A gateway outage during peak season is lost revenue; the router lets checkout fail over without the page knowing.

    Trade-off · Every gateway's quirks must be normalised into one contract, and retries need idempotency keys to never double-charge.

  2. 02Splitting PHP and Node

    PHP renders, Node integrates.

    Slow partner APIs are isolated from page rendering, so one supplier's latency never slows the storefront.

    Trade-off · Two runtimes to deploy and monitor.

  3. 03Caching strategy

    Cache whole pages; purge on publish.

    Destination pages are read thousands of times per edit - sub-second navigation comes from never rendering them twice.

    Trade-off · Anything personalised must stay out of cached HTML and load separately.

Concepts in this system