Technical Interview: Architecture Section

Two non-functional requirements caught the candidate's eye: car parks spread across cities all over Russia, plus high availability — which already rules out a single data centre. Concrete request rates were skipped, leaving only the assumption that load will grow as the business does. The back office, where new car parks are registered and paperwork is handled, was pushed out of scope, and so was payment processing, treated as somebody else's system.

Access control was declared external too: a barrier with a camera reading licence plates. Rather than design it, they agreed to consume two events from it — car in and car out. The parking model was simplified as well: no floor plan, no specific bay assigned, just a counter of free spots per car park. The candidate, a long-time aviation engineer, kept calling them seats, as on a plane. Overbooking was ruled out on purpose.

The interviewer added a scenario the candidate had not reached: users look not at one car park but at a rectangle on the map — a shopping centre and everything around it. That pulled in a geo index on coordinates and the realisation that the query is both heavy and constantly changing, since people pan the map and refresh. Car park coordinates are safe to cache, as they rarely change; free-spot counters are not, and caching them for writes is out of the question.

The core turned out to be an atomic decrement that refuses to go below zero — effectively a semaphore. Not read the value and write one less, but an operation that returns a failure at zero, so the app can say the spots were taken while you were thinking. Cancellations and departures increment it back. For bookings unconfirmed by arrival within fifteen minutes the candidate introduced a delayed-message queue, plus a second queue for notifications. Splitting by coordinates needs no counter synchronisation across regions.

The debrief opened with strengths: the boundaries were drawn cleanly, whereas candidates often bury themselves by agreeing to build everything at once. The gap was a missing entity — the orders themselves. The candidate accepted it and added a booking history: the full stream of user events with their outcomes, essentially write-only, in a log-oriented store fed from a shared event bus. He noted the irony himself, since he does data science and usually scolds others for data nobody collected.

The interviewer's own solution went another route: PostgreSQL with a constraint keeping the counter non-negative, plus an explicit order status model — created, paid, driver arrived, timer running. Read load on the map was served from a separate copy of the data, accepting the lag where a user sees the last free spot and is refused at booking. Geographic scaling, in his view, is simpler at the traffic-balancing layer: nobody books in Vladivostok and Moscow at the same moment. He also noted the session ran thirty minutes instead of the usual hour.