Top Swiggy Backend Engineer Interview Questions 2026

Geospatial index (geohash or H3) of available partners. On order: query candidates within radius, score by (distance + idle time + rating + current load + direction match). Send offer with 30-second timeout; on reject, escalate weights or expand radius. Reassignment loop with budget. Surge incentives during peak demand. Anti-starvation rules so high-rated partners don't always win premium orders.

Use a geospatial index — R-tree, k-d tree, or geohash buckets in Redis (GEOADD/GEORADIUS). Query restaurants within the delivery radius. Filter by serving the user's location, open/closed status, in-stock items. Rank by composite of distance + rating + ETA. Handle boundary conditions: user near edge of two cities, restaurants at the radius edge.

ML model with features: historical delivery times for this (restaurant, distance) bucket, real-time traffic (Google/Mapbox API), time of day, weather, restaurant prep time (their recent average), partner availability. Output ETA with confidence interval. Update live as the order progresses (prep done, picked up, en route). Re-train weekly with retrospective data. Calibration check: predicted vs actual.

Fixed-size array with front and rear pointers and a count (or use modulo with empty/full distinction). enqueue: rear = (rear + 1) % capacity, increment count. dequeue: front = (front + 1) % capacity, decrement count. isFull: count == capacity. isEmpty: count == 0. O(1) for all ops. Thread-safe variant uses a lock or atomic CAS for lock-free.

Per-dark-store, per-SKU inventory counts. Redis as the real-time source for fast reads; DB as source of truth for durability. Reservation on cart-add (TTL of N minutes), commit on payment, release on abandon. Atomic DECR for over-sell prevention. Automatic reorder triggers when stock crosses threshold. Periodic reconciliation (physical count vs system count) with audit.

For small scale (k partners, k orders), Hungarian algorithm gives optimal assignment in O(k³). For large scale (thousands per dispatch window), greedy nearest-neighbor or auction algorithm in O(k²) or O(k log k). Batch optimization every N seconds rather than per-order improves global cost. Constraint: respect partner-order compatibility (vehicle type, max distance).

Compute demand/supply ratio per geohash + 5-min window. Demand = active orders + open carts. Supply = available partners. Surge multiplier mapped from ratio with caps to avoid extreme pricing. ML model improves predictions for upcoming demand (rainy day, IPL match). Customer sees estimate upfront; partner gets corresponding incentive. Audit log for every surge decision (regulatory).

Store restaurant lat/lng + radius. Compute Haversine distance from partner's current position. Use Redis GEOADD for partners + GEORADIUSBYMEMBER to find nearby restaurants for each location update. Trigger an event on entering the geofence (e.g., notify restaurant the partner is here). Hysteresis: small buffer to avoid flapping if partner is on the boundary.

OpenTelemetry SDK in every service for instrumentation. W3C Trace Context propagation across HTTP/gRPC/Kafka. Spans exported via OTLP to a collector. Storage in Jaeger or Tempo with sampling (head-based, tail-based, or adaptive — tail sampling captures all error traces). UI for trace exploration. Alerting on latency anomalies (P95 spike on a critical span).

Redis sorted set per leaderboard scope (city, week). ZADD on each delivery completion (score = cumulative deliveries or weighted points). ZRANGE / ZREVRANGE for top-K with pagination. ZRANK for an individual partner's rank. Reset weekly: copy current set to archive, clear active set. Use Lua for atomic updates if multiple metrics combine.

Cache warming before the restaurant opens — pre-populate menu, item data, and image URLs. Request coalescing: only one in-flight DB read per cache key, other waiters subscribe to its result. Add jitter to cache expiries to prevent synchronized stampedes. Gradual cache population with a probabilistic early-refresh (XFetch). Rate-limit the backing store with a circuit breaker.

States: PLACED → ACCEPTED → PREPARING → PICKED_UP → OUT_FOR_DELIVERY → DELIVERED. Plus failure states: CANCELLED, RETURNED. Each transition emits a Kafka event. Timeout handlers per state (e.g., 5 mins to accept; else auto-reassign restaurant). Dead-letter queue for stuck orders. Push notifications and SMS on each customer-visible transition. Idempotent transitions guarded by state check (DB version).

Doubly linked list + hash map. Hash map: key → node. List: most-recently-used at head. get: hash lookup, move node to head, return value. put: if exists, update and move to head; else add to head; if over capacity, evict tail (remove from map and list). O(1) for both ops. In Java: LinkedHashMap with accessOrder=true.

Event streaming: services publish to Kafka. Flink job aggregates rolling windows (orders/min by city, avg ETA, partner availability). Redis holds live metrics for low-latency reads. WebSocket from dashboard fetches updates. Pre-aggregated hourly/daily rollups stored in ClickHouse for historical queries. Alert rules in Prometheus for anomalies.