Core Entities
Flight: flight_id, flight_number, airline_id, origin_airport, destination_airport, scheduled_departure, scheduled_arrival, actual_departure, actual_arrival, status (SCHEDULED, BOARDING, DEPARTED, ARRIVED, DELAYED, CANCELLED), aircraft_id, gate_id. Gate: gate_id, terminal, gate_code (A12), gate_type (domestic, international), is_available, current_flight_id. Passenger: passenger_id, name, passport_number, frequent_flyer_id. Boarding Pass: pass_id, passenger_id, flight_id, seat_number, boarding_zone, barcode, is_boarded. Baggage: bag_id, passenger_id, flight_id, rfid_tag, weight_kg, status (CHECKED_IN, LOADED, IN_TRANSIT, DELIVERED, MISSING).
Gate Assignment
Gate assignment must balance terminal utilization and aircraft type constraints. Algorithm: for each incoming flight, find available gates in the required terminal (domestic/international) that are compatible with the aircraft size. Score candidate gates: prefer gates adjacent to the same airline other flights (improves connection convenience), prefer gates with appropriate jetbridge type for the aircraft. Check gate availability: gate must be free for [arrival_time – 30min, departure_time + 30min] to allow turnaround. Conflict detection: query all flights using the gate and check time overlap. Assign and lock the gate. Reassignment on delay: if a delayed flight conflicts with the next scheduled gate user, trigger reassignment for one of the two flights.
class GateAssignmentService:
def assign_gate(self, flight: Flight) -> Optional[Gate]:
window_start = flight.scheduled_arrival - timedelta(minutes=30)
window_end = flight.scheduled_departure + timedelta(minutes=30)
candidates = self.db.get_available_gates(
terminal=flight.required_terminal,
aircraft_type=flight.aircraft.type,
from_time=window_start,
to_time=window_end
)
if not candidates:
return None
return min(candidates, key=lambda g: self.score_gate(g, flight))Boarding Process
Boarding zones: passengers are grouped into zones (1-5) to reduce aisle congestion. Boarding order: zone 1 (first class, special assistance) first, then zones 2-5 back to front. Boarding pass validation at the gate: (1) Scan barcode. (2) Verify flight matches the gate current flight. (3) Check boarding_pass.is_boarded is false (prevent double boarding). (4) Verify the boarding time is within the allowed window. (5) Set is_boarded = true. (6) Decrement remaining_boarding_count on the flight. API endpoint: POST /gate/{gate_id}/board with the barcode. Boarding starts 45 minutes before departure. Gate closes 15 minutes before departure: passengers not yet boarded are offloaded (bag removal required for safety).
Baggage Tracking
Each bag has an RFID tag scanned at multiple checkpoints: check-in counter, baggage screening (TSA), baggage sorting (conveyor system), loading onto aircraft, arrival carousel. At each checkpoint: scan RFID -> log BaggageEvent(bag_id, checkpoint, timestamp, location). Update bag.status based on the checkpoint sequence. Misconnect detection: if a passenger is rebooked due to a delay, their bags may be on the original flight. Bag tracking system detects: bag is tagged for Flight A, passenger is now on Flight B. Alert the baggage team to retrieve the bag. Lost bag: if the bag has no scan event for 2+ hours, alert the operations team and the passenger. Weight validation: scale at check-in records weight; if over the limit (23kg), charge excess fees.
Delay Propagation
A flight delay creates cascading effects. When Flight A is delayed: (1) Notify passengers via push notification and email. (2) Update the gate display. (3) Check connecting passengers: passengers on Flight A who have a connection to Flight B with less than the minimum connection time (MCT) + delay. For each affected connection: alert the airline operations, possibly hold Flight B. (4) Check crew scheduling: if the delay pushes the crew duty hours beyond legal limits, reassign crew. (5) Gate conflict: if the delayed departure conflicts with the gate next assignment, trigger gate reassignment. Delay cascades can be modeled as a graph: each flight is a node; edges represent connections. Propagate delays through the graph with BFS.
Real-Time Displays and Notifications
Airport display boards (FIDS — Flight Information Display System) show real-time status. Data source: airline operations system pushes updates via Kafka. The airport management system consumes events and updates: database flight records, FIDS displays (WebSocket push to display controllers), passenger mobile app notifications (push via APNs/FCM), airline lounge displays. Update latency target: under 5 seconds from status change to display update. For passenger notifications: only send when status changes significantly (delay > 15 minutes, gate change, boarding open). Filter to affected passengers using flight_id. Notification history stored for compliance.
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How do you prevent double boarding the same passenger?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Each BoardingPass has an is_boarded boolean field. When a passenger scans at the gate: (1) SELECT the boarding pass by barcode. (2) Verify flight_id matches the current gate flight. (3) Check is_boarded is false — if true, reject (already boarded). (4) UPDATE boarding_passes SET is_boarded=true WHERE pass_id=X AND is_boarded=false. Check rows_affected: if 0, a concurrent scan already set it to true (reject). (5) If rows_affected=1: open the gate. The conditional UPDATE is the race-condition guard — only one scan can set is_boarded from false to true. Additionally, the system timestamps the boarding event for audit trails and crew manifests.”
}
},
{
“@type”: “Question”,
“name”: “How does gate assignment handle last-minute flight delays?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “When a flight is delayed, the gate assignment service re-evaluates conflicts: query all other flights using the same gate and check if the delayed departure now overlaps with their scheduled arrival or departure windows (including turnaround buffers). If a conflict is detected: the system identifies the lower-priority flight (usually the one with more flexibility in arrival buffer) and triggers reassignment. The reassignment algorithm searches for an available gate in the same terminal with no overlapping flights in the new window. If no gate is found, escalate to the operations team for manual resolution. Passengers are notified of gate changes via push notification with a 10-minute buffer before the gate change takes effect.”
}
},
{
“@type”: “Question”,
“name”: “How do you track baggage end-to-end with RFID?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “At check-in: scan the RFID tag on the bag and link it to (passenger_id, flight_id, bag_id). Create a BaggageScan record with checkpoint=CHECK_IN, timestamp, and handler_id. The bag moves through checkpoints: SCREENING (TSA scanner), SORTING (conveyor), LOADED (recorded by ramp agent), ARRIVED (carousel sensor), DELIVERED (passenger claim). At each checkpoint: RFID reader logs a scan event. The tracking system detects anomalies: if a bag expected at SORTING does not appear within 30 minutes of CHECK_IN, alert the baggage team. For misconnected passengers: compare bag.flight_id to passenger.current_flight_id; if different, trigger an intercept request to retrieve the bag before loading.”
}
},
{
“@type”: “Question”,
“name”: “How does the minimum connection time system work?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Minimum Connection Time (MCT) is the minimum time a passenger needs to make a connecting flight: deplane, transit the airport, and re-board. MCT varies by: connection type (domestic-domestic, domestic-international, international-domestic), terminal (same terminal is faster than cross-terminal), and airport. Store MCT values in a connection_rules table: (origin_terminal, destination_terminal, connection_type) -> minimum_minutes. When a flight is delayed: compute affected connections. For each passenger on the delayed flight with a connection: effective_connection_time = connecting_flight.scheduled_departure – (original_arrival + delay). If effective_connection_time < MCT[connection_type]: flag as missed connection. Alert the airline operations for potential rebooking or holding the connecting flight."
}
},
{
"@type": "Question",
"name": "How do you scale a real-time flight status display system?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Flight status data originates from airline operational systems and flows via Kafka topics (one topic per airline or event type). The airport management service consumes these events, updates the flight records in PostgreSQL, and publishes status changes to a Redis pub/sub channel. FIDS (Flight Information Display System) controllers subscribe to the relevant Redis channels and update display boards in real time. For mobile apps: use WebSocket connections (Socket.io or native WebSocket). On status change: push to all connected clients subscribed to that flight_id. Scale the WebSocket tier horizontally — route all clients for a flight to the same shard (consistent hashing on flight_id) to avoid cross-server message delivery. CDN caches static assets; dynamic data flows through WebSocket."
}
}
]
}
Asked at: Uber Interview Guide
Asked at: Airbnb Interview Guide
Asked at: Lyft Interview Guide
Asked at: Shopify Interview Guide