How We Search 300+ Airlines in Under 3 Seconds

When you search for a flight on Pointify, a lot happens in the two to three seconds before results start appearing. This post walks through what is actually running on our backend—the data sources, the streaming protocol, and the points optimization layer that makes Pointify different from a generic metasearch engine.

The Deal Engine

Our backend is a Python FastAPI service we call the “deal engine.” When a search request arrives, it fans out to multiple data sources in parallel using Python’s asyncio:

• Duffel NDC — Direct airline connections for real-time, bookable pricing from 300+ airlines. This is our primary data source and typically responds in 500ms–2 seconds.
• Google Flights scraper — Browser automation with Playwright captures fare data that Google aggregates from its own airline relationships. Response time: 2–4 seconds.
• Award databases — Seats.aero and custom integrations for points availability across 20+ loyalty programs. Response time: 1–3 seconds.
• Transfer partner calculations — Real-time computation of optimal transfer paths from credit card programs. This is CPU-bound and completes in under 500ms.

Server-Sent Events (SSE)

Rather than waiting for all sources to respond, we stream results to the browser as they arrive using Server-Sent Events. This is a critical architectural decision—the alternative (waiting for all sources, then sending one response) would mean a 4–6 second delay before showing anything.

With SSE, the experience feels instant. The first results from Duffel typically appear in under one second. Google Flights data follows around 2–3 seconds later. Award availability trickles in over the next few seconds. The frontend handles progressive rendering, sorting, and re-ranking as new results arrive.

From the user’s perspective, they see results building up in real time—not staring at a spinner wondering if the search is actually working.

Points Optimization Layer

For every cash fare we find, our points optimizer runs a parallel calculation: “Could this route be cheaper with points?” The optimizer checks 20+ loyalty programs, considers current transfer bonuses, and computes the cents-per-point value for each option.

The optimization is modeled as a weighted directed graph where nodes are currency programs (Chase UR, Amex MR, airline miles) and edges are transfer relationships with associated ratios and bonuses. Finding the cheapest points path is a shortest-path problem solved with modified Dijkstra’s algorithm.

Infrastructure

• Compute: Python FastAPI with uvicorn, running on AWS ECS with auto-scaling. The async architecture means a single container handles hundreds of concurrent searches.
• Frontend: Next.js on Vercel with edge functions for the API proxy layer. The SSE connection is established directly between the browser and the deal engine through our proxy.
• Database: PostgreSQL (RDS) for search history, user data, and fare caching. Redis (ElastiCache) for rate limiting, session management, and hot-route caching.
• Browser automation: A pool of Playwright browser instances managed with a custom lifecycle system for the Google Flights scraper. Browsers are pre-warmed and recycled to minimize cold-start latency.

The entire search pipeline—from your click to the first result on screen—averages 800ms. The full result set is typically complete in 3–5 seconds.

What’s Next

We are pushing the architecture further with predictive prefetching on the search form (start loading data before you click “Search”), a per-route warm cache for popular queries, and a fare prediction model that will tell you whether to book now or wait. Expect deeper engineering posts as we ship each layer.