← Airbnb Interview Insights

Airbnb·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say
Jul 2026

Summary

Airbnb system design round for a software engineer role. The whole thing was basically one long deep-dive on frontend network efficiency, which I was not expecting to be so broad.

Questions Asked (1)

Q1

How would you reduce redundant frontend network requests for availability and pricing data? Walk through batching endpoints, GraphQL, request coalescing and deduplication, HTTP/2 multiplexing, client-side caching with cache keys and TTLs, and pagination or windowing. Include an example API schema or query, discuss the trade-offs around latency, payload size, cacheability, and observability, and describe how you'd monitor and safely roll out the change.

System DesignTechnical Trade-offsAPI & Integrations
Author's notes

This question was way bigger than I anticipated.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the problem scope and current pain points, then systematically walk through each technique (batching, GraphQL, coalescing, HTTP/2, caching, pagination) with concrete examples and trade-offs. Emphasize measurement, monitoring, and safe rollout to show production maturity.

Pro tip: Frame your answer around reducing redundant requests while balancing latency, payload size, and cacheability—and always mention how you'd measure success with metrics like request count, cache hit rate, and p95 latency before and after.

1. Clarify requirements and current state

Ask about the current architecture, request patterns, and pain points (e.g., duplicate calls, waterfall requests). Identify key metrics like request volume, latency, and cache hit rate to establish a baseline.

2. Evaluate batching and GraphQL

Discuss batching multiple availability/pricing queries into a single endpoint (e.g., POST /batch) or using GraphQL to fetch exactly what's needed in one round trip. Provide an example schema or query.

3. Implement request coalescing and deduplication

Explain how to deduplicate identical in-flight requests (e.g., using a promise cache) and coalesce multiple requests for the same data into one. Mention HTTP/2 multiplexing to reduce connection overhead.

4. Design client-side caching with cache keys and TTLs

Describe cache key design (e.g., listing ID + date range + guest count) and TTL strategies (short for pricing, longer for availability). Discuss cache invalidation and storage (memory, sessionStorage).

5. Address pagination/windowing and trade-offs

Cover pagination or windowing for large result sets, and analyze trade-offs: latency vs. payload size, cacheability vs. freshness, and observability needs. Outline monitoring and safe rollout (feature flags, canary, A/B test).

Key Points to Mention

  • Batching endpoints (e.g., POST /batch with array of queries) and GraphQL to reduce round trips
  • Request coalescing/deduplication using in-flight promise caches and HTTP/2 multiplexing
  • Client-side caching with well-designed cache keys and TTLs, plus cache invalidation strategies
  • Pagination/windowing to limit payload size and improve perceived performance
  • Trade-offs: latency vs. payload size, cacheability vs. freshness, and impact on observability
  • Monitoring metrics (request count, cache hit rate, p95 latency) and safe rollout via feature flags and canary releases

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.