FlyGhor

Online Travel Agency (OTA)

Maintenance

2022

Team

004

Year

2022

Duration

3 months

Team

2 engineers

Role

Team Leader & Backend Developer

Scalable microservice-based OTA with real-time airline integrations

Overview

FlyGhor is a full-featured Online Travel Agency (OTA) platform built on a microservice architecture to support scalable and reliable travel booking services. As Team Leader and Backend Developer, I led the backend development team, designed and implemented core microservices, reviewed code, and collaborated with frontend and product teams to deliver new features. The platform integrates airline APIs for real-time flight availability, fare validation, booking confirmation, PNR management, and cancellations. The backend was designed with asynchronous processing, message queues, retry mechanisms, webhook event handling, JWT-based authentication, role-based access control, and RESTful APIs to ensure high availability, fault tolerance, and seamless communication between services.

Key Achievements

Full booking lifecycle: search → validate → book → confirm → cancel

Circuit breaker pattern prevents cascade failures during FitsAir outages

Bull-powered retry queue with exponential backoff for failed API calls

Webhook receiver for real-time PNR status updates from FitsAir

Clean internal REST API fully abstracts FitsAir's proprietary schema

Comprehensive request/response logging for dispute resolution

Technical Challenges

API rate limiting and timeouts

FitsAir's API enforces strict rate limits and occasionally times out under load, causing booking failures to cascade into the main OTA system.

SOLUTION →Implemented a circuit breaker that opens after 5 consecutive failures, pausing all requests for 30 seconds before probing. This prevents OTA degradation while FitsAir recovers.

Guaranteed booking delivery

A network drop mid-booking could leave a booking in a partially confirmed state with no reliable way to reconcile.

SOLUTION →Introduced idempotency keys on all booking requests. If a request fails after FitsAir has confirmed, the retry returns the existing PNR instead of creating a duplicate booking.

Schema mapping complexity

FitsAir uses a bespoke XML-based schema with airline-specific field names that don't map cleanly to the OTA's internal booking model.

SOLUTION →Built a bidirectional mapping layer with strict TypeScript types on both sides. Any unmapped field throws at compile time — making schema drift a build error, not a runtime surprise.

metrics.json

99.95%

Availability

<150ms

Avg Latency

96%

Retry Success Rate

100%

Webhook Accuracy

200+

Daily Bookings

<30s

Timeout Recovery

Technology

Service

Node.jsTypeScriptExpress microservice

Resilience

Bull job queueCircuit breakerExponential backoff

Database

PostgreSQL (bookings)Redis (job queue store)

Transport

Axios (outbound)Webhooks (inbound)REST internal API

Infra

Docker containerNginx sidecarHealth checks

Resources

Live Site

Development Timeline

PHASE 01 — API Analysis

FitsAir API docs reviewAuth flowSchema mapping designError catalogue

Back

epaper cms

naria holidays