// May 2025 — Oct 2026
Travel booking management platform
On the Beach
Senior .NET / React Engineer · UK online travel
Large UK travel booking platform for 1M+ customers in the UK and Europe, wanted to dominate the market and compete on hotel availability, pricing with 3rd-party supplier integrations across their search pipeline.
- Search response
- 3s to 200ms
- Suppliers covered
- 160
- Customers
- 1M+
- Faster migration delivery
- 30%
Context
Search results were assembled by querying suppliers over REST at request time. It was slow, and it timed out often. Several services also kept their own availability and cache state according to their own internal business logic, so there was no single answer to what was actually bookable. Both the cache layer and the availability microservice ran on SQL Server.
The hard part
The bottleneck was concurrency, not query speed. Even with an execution plan hand-tuned for concurrent writes, SQL Server would discard it and compile a new one under load; many simultaneous compilations spiked CPU and memory and pushed the ingestion pipeline into timeouts. The obvious remedy — pessimistic locking across whole rows — would have serialised precisely the writes that needed to run in parallel, so the fix had to come from the shape of the data and the query plan rather than from locking.
Outcome
Search now resolves against a pre-computed hash table rather than fanning out over REST, taking response times from three seconds to 200ms. The cache layer moved from SQL Server to DynamoDB as the single source of truth for every downstream search system, and the availability microservice for 160 suppliers moved to PostgreSQL with ElastiCache (Redis) for high-volume data. A Databricks and .NET pipeline keeps the primary cache fresh for the most popular searches, and a Redis-backed distributed semaphore with Polly retries and Nginx rate limiting keeps supplier integrations stable under high load.
The work
- 01
Drastically improved search response times for low-latency reads at high throughput from 3s to 200ms, by searching in the database for availability combinations based on a pre-computed hash table and by re-using precalculated combinations from hashes for day availability.
- 02
Scaled the Inventory Management System, by migrating the cache layer from SQL Server to DynamoDB, by consolidating all supplier data into a single source of truth for all downstream search systems.
- 03
Streamlined search availability from 160 suppliers, by improving the REST microservice performance, by migrating from an SQL Server to PostgreSQL to handle high-volume data using Amazon ElastiCache (Redis) and C# and .NET.
- 04
Eliminated availability gaps and stale cache data in the event-driven architecture by designing a Databricks and .NET microservice pipeline that auto-queries suppliers for fresh details for the primary cache for most popular searches.
- 05
Strengthened supplier integration stability by implementing a Redis-backed distributed semaphore with a token bucket, with slot limits under high load, and retry policies using Polly for resilience and rate limiting with Nginx.
- 06
Developed a greenfield module for a centralized supplier configuration system using React.js and .NET APIs.
- 07
Used AI-assisted development (Claude Code, Cursor) daily for implementation, refactoring and test generation, cutting delivery time on migrations by 30%, and built custom Claude Code skills, subagents and hooks for the team.
Stack
- C# 14
- .NET 10
- React.js
- Databricks
- RabbitMQ
- New Relic
- Docker
- Redis
- PostgreSQL
- SQL Server
- Dapper
- LINQ
- MassTransit
- Scrutor
- Polly
- xUnit
- Shouldly
- NSubstitute
- Amazon Aurora
- Amazon DynamoDB
- Amazon CloudWatch
- Amazon ElastiCache
- Terraform
- ArgoCD
- Claude Code
- Cursor
// Get in touch
Working on something similar?
Crisify is taking on new engagements — audits, embedded work and advisory, remote across the EU.
No obligation · Response within 24 hours