A developer built Flight33 as a full-stack flight search engine for a frontend assessment, treating it as a system design problem rather than a UI-only task. The architecture uses a server layer to integrate with the rate-limited Amadeus API, enforcing a stable data contract and implementing a global caching strategy to keep latency low under repeated queries.

All search requests route through the server, which handles cache resolution, external API calls, and response normalization. The system uses Redis for caching, keyed deterministically by search parameters, not per user. This design isolates the client from API volatility, ensuring predictable performance while reducing redundant upstream requests.

Client-side filtering operates on the initial in-memory dataset, avoiding extra network calls. The trade-off assumes manageable result volumes and accepts short-lived cache staleness. For larger-scale systems, filtering and pagination would likely shift server-side. Flight33 demonstrates how centralizing API access and caching identical searches can create a responsive, predictable search experience.