Field report: airport parking platform cutover

Design, implementation and production cutover of a new public booking platform for a regional airport parking operator. The service combined online reservations and payments with onsite ANPR, QR validation, variable-message signs and automated entry and exit lanes.

Assignment record

13 January — Initial engagement

The operator’s existing booking website had reached the end of vendor support and could not expose live capacity consistently across its separate car parks. Customers received a booking reference by email, but number-plate changes and delayed updates frequently required assistance at the barrier. Mobile completion rates had declined as the original fixed-width checkout aged.

The requested replacement would provide responsive booking, live product availability, pre-book discounts, amendments, cancellation and stored customer vehicles. Confirmed bookings had to reach the airport lane estate within two minutes. On arrival, a matching number plate would open the relevant entry barrier; the booking QR code would provide a secondary credential where recognition failed.

27 January — Service discovery

Workshops followed the customer journey from search through airport arrival, return and exit. Separate sessions covered yield management, overstay charging, payment settlement, customer service, barrier operation and recovery during loss of connectivity.

The estate comprised a multi-storey short-stay facility, two surface long-stay areas, staff parking and a coach lane. Twenty-two automated lanes used three generations of controller supplied by the same access-equipment vendor. Each reported plate reads, loop-detector state, ticket events, barrier position and fault codes to an onsite management server.

Airport operations required the lane systems to continue accepting recently synchronised bookings during an external-network outage. The public platform therefore could not issue direct barrier commands. It would publish booking entitlements to an onsite edge service, which would make local admission decisions and return entry, exit and occupancy events.

12 February — Functional specification

The signed specification separated a booking from the credential used at the site. A booking could contain multiple historic plate values, but only the currently active plate and QR token would be accepted. Changes made within two hours of arrival would receive priority synchronisation to the edge system.

Tariff search considered dates, flight terminal, capacity, advance-purchase band, promotional code and accessible-space requirements. Price was reserved for fifteen minutes during checkout. The payment provider’s hosted fields kept card data outside the application, while webhook confirmation completed the booking independently of the customer returning to the site.

At the lane, a successful entry consumed the inbound entitlement and established an onsite stay. Exit required the matching stay, or a local payment for an overrun. Idempotency keys protected booking updates and event receipts from ordinary network retry.

03 March — Experience design

Design proofs covered search, product comparison, passenger guidance, checkout, confirmation, account history and booking amendment. Mobile screens prioritised arrival date, return flight and registration number without reducing the tariff explanation or cancellation conditions.

Prototype testing found that customers frequently confused the letter O with zero in registration plates. The final field retained the entered value, displayed a normalised preview and asked for confirmation before payment. Booking confirmations included the plate in large type, a wallet-compatible QR credential and directions to the selected car park.

The operator approved the component set after two review rounds. Content was written for normal arrival, an unrecognised plate, early entry, overstay, lost QR code and a full car park. Accessibility checks covered keyboard use, error summaries, 400% zoom and screen-reader announcement during tariff updates.

17 March — Platform architecture

The public application used Symfony 7 on PHP 8.3 with PostgreSQL 16 for bookings, tariffs and payment state. Redis 7 provided short-lived quotation and session data. Server-rendered HTML was enhanced with small JavaScript components so search and checkout remained recoverable through ordinary requests.

Application nodes ran across two UK availability zones behind a managed load balancer. Object storage held generated confirmations and tariff exports. Monitoring covered HTTP journeys, queue depth, payment webhooks, booking synchronisation delay and the age of the latest event from each lane.

31 March — Messaging contract

Booking entitlements were published to a site-specific topic and acknowledged only after the edge database committed them. Lane observations travelled in the opposite direction. A separate command family allowed authorised onsite operations staff to raise a named barrier, close a lane, change a sign or place a controller into attended mode.

Messages shared an envelope containing event identifier, site, lane, creation time, expiry and payload version. Observation and entitlement consumers rejected duplicate identifiers. The vendor command adapter did not retain idempotency state because a repeated physical command was assumed to produce the same requested position.

Messages that failed schema validation or exceeded their retry limit moved to a dead-letter exchange. The operations console allowed selected records to be inspected and replayed after correction. The replay function was tested using booking and observation events; actuator commands were excluded from the test dataset.

14 April — Onsite integration

The edge server was installed in the car-park control room and connected to the lane-management VLAN. Controller identities, direction, vehicle-loop inputs, sign channels and local tariff tables were imported from the existing management server. Each configured lane was reconciled against its cabinet label and physical location.

A temporary test booking was presented at every entry. ANPR and QR credentials opened the expected barrier, occupancy increased once the closing loop cleared and the corresponding exit accepted the recorded stay. Loss of each external circuit demonstrated that local bookings remained available and that event messages queued until connectivity returned.

The coach lane and staff car park used similar eight-character controller prefixes. Their full identifiers remained distinct in the edge configuration and on the vendor management screen. An older diagnostic export shortened both prefixes for display but was not used by the application at that stage.

05 May — End-to-end acceptance

Acceptance used 600 synthetic bookings across normal, amended, cancelled, early, late and duplicate-plate scenarios. Payment success and failure, delayed webhook delivery, customer abandonment and refund were reconciled to the booking ledger. The edge system received all valid entitlement changes within the two-minute requirement.

Load testing sustained the expected summer peak with capacity remaining at the public platform and message broker. A simulated four-hour site disconnection generated 38,000 lane observations; once restored, they drained in sequence without affecting new booking delivery. No barrier command was included in that simulation.

The operator’s customer-service team completed account searches, plate changes, resend, cancellation and manual credential issue. Lane supervisors tested attended mode and individual barrier release from the operations console. The service was approved for cutover.

03 June — Production cutover

New sales were paused at 00:30 while future bookings were exported from the legacy database and imported into the new platform. Record counts, payments, active plate credentials and arrival dates reconciled. DNS moved to the new public service and existing customer sessions were allowed to expire.

The edge server received 86,412 future entitlements and reported a matching checksum. Test vehicles entered and exited each car-park class using both number plate and QR code. Variable-message signs displayed the expected capacity, and the legacy booking system was placed in read-only mode.

Sales resumed at 03:58. By the end of the first operating day, 1,842 bookings had been completed, all payment batches reconciled and median site-synchronisation delay remained below eleven seconds.

07 June, 04:42 — Site circuit interruption

Four days after cutover, both WireGuard tunnels began alternating between available and unavailable as the primary site circuit experienced packet loss and the backup circuit changed route. The edge system continued making local admission decisions and retained outbound lane events as designed.

Short interruptions caused messages to be delivered more than once before acknowledgement. Duplicate observations were rejected correctly by the public consumer. A smaller set failed because the controller firmware populated lane timestamps from its own clock, which was seven minutes ahead of the edge server and outside the accepted event window.

At 05:26 connectivity stabilised. Current entitlements resumed immediately, while 6,812 rejected observations accumulated in the dead-letter exchange. Public bookings and local lane operation remained available.

06:18 — Exit discrepancy reported

The control room reported that several vehicles appeared onsite in the lane-management screen but not in the customer-service view. Exit barriers still opened after lookup against the edge database, although the central occupancy dashboard understated the number of stays and two customers received an incorrect overstay prompt.

The attending support engineer confirmed that the dead-lettered messages contained the missing entry observations. Their schemas were valid and their only common failure was timestamp tolerance. Because the controller clocks had now synchronised, replaying the records with their original identifiers was expected to reconstruct central stay state without altering the lane.

06:37 — Dead-letter replay

The support engineer selected the affected site and issued a replay against the topic pattern parking.#, preserving original order. The command was intended to cover entry, exit and occupancy observations for every public lane. The console reported 6,812 selected messages and began republishing them in batches.

The dead-letter exchange had also retained 214 actuator messages generated during acceptance and early operations. These included individual raise, lower, attended-mode and sign-test commands whose initial acknowledgements had been lost even though their physical actions had completed. They matched the same topic pattern.

During dead-letter handling, the original site-routing header had been moved into a diagnostic field that the replay tool did not restore. The edge adapter therefore resolved each actuator payload using its shortened controller identifier rather than the complete site and lane key.

06:39 — Historical commands executed

Barrier arms across the estate began changing position in the sequence used during acceptance testing. Some entry lanes raised and immediately lowered; others entered attended mode or printed test tickets. Variable-message signs alternated between FULL, CLOSED and unrestricted capacity values.

Controllers receiving a replayed lower command obeyed their vehicle-loop safety input and remained raised where a vehicle was directly beneath the arm. Controllers without an occupied loop lowered normally. The resulting state differed from lane to lane and from the status shown in the central console.

Three coach-lane commands resolved to public multi-storey controllers with the same shortened prefix. Their configuration included a different direction flag, causing the edge service to treat two exits as entries and to reject vehicles already recorded inside under anti-passback rules.

06:43 — Automated configuration recovery

The monitoring service identified unexpected controller state and initiated the vendor adapter’s automatic reconciliation. It compared each reporting lane with the stored desired configuration and sent a complete profile where they differed.

Because the diagnostic identifier had already collapsed the coach and multi-storey prefixes, the reconciliation process assigned the coach template to four public lanes. Direction, loop sequence, sign channel and barrier timeout changed together. One entry became an exit, two exits became entries and a height-warning relay was associated with an ordinary short-stay lane.

New ANPR events now created state changes against the wrong direction. Vehicles admitted minutes earlier were recorded as having departed, while vehicles attempting to leave were treated as fresh arrivals without a valid inbound entitlement.

06:51 — Traffic begins to accumulate

Queues formed first at the multi-storey exits and then across internal circulation lanes. Intercom calls increased faster than the two control-room staff could answer. Raising a barrier through the console worked temporarily, but the replay or reconciliation process sent a subsequent command and returned it to another state.

At entry, open barriers admitted vehicles without establishing a valid stay. Other lanes displayed FULL and remained closed despite available capacity. Drivers changed lanes, reversed from approach channels and blocked the routes needed by airport buses and recovery vehicles.

The operator instructed staff to place every public lane into local manual control. The physical release keys were held in a locked control cabinet. Its electronic cabinet lock depended on the same access-management network and did not release when the controller state became inconsistent. The mechanical master key was kept at the parking contractor’s office seventeen miles away.

07:02 — Local network intervention

An onsite engineer connected a commissioning laptop to the service switch at the multi-storey entrance. To reach the exit controllers from the same diagnostic session, a spare patch lead was placed between the entrance and exit service switches.

The two switches were already connected through the car park’s fibre distribution ring. The service ports were unmanaged extensions without spanning-tree protection. The additional cable completed a layer-two loop, and broadcast traffic multiplied across the lane-management VLAN.

ANPR cameras, intercoms, payment terminals, signs and controllers stopped responding to management within seconds. The edge server remained online but could no longer distinguish a silent lane from one changing state. Its queued reconciliation messages continued to accumulate.

07:05 — Local fallback state

On loss of their management heartbeat, newer exit controllers entered the configured fail-open position. Older controllers retained their last physical state. Two recently reprofiled controllers applied the coach-lane fallback, which lowered the barrier and activated a height-warning arm intended for oversized vehicles.

Drivers encountering open exits moved forward at the same time as traffic was reversing from closed lanes. Two vehicles made low-speed contact near the merge. A terminal luggage shuttle entered a lane whose barrier had started to rise and then stopped approximately one metre above the road surface.

The shuttle continued beneath the partially raised arm. The arm caught on its roof-mounted ventilation housing and was pulled from the barrier mechanism. Still attached by its control cable, it rotated into the overhead clearance frame and displaced the frame toward the car-park ceiling.

07:06 — Sprinkler main damaged

The displaced clearance frame struck a sprinkler branch connection beneath the concrete deck. The threaded joint fractured and released water across the exit lanes. The fire-system flow switch interpreted the sustained discharge as sprinkler activation and raised a building fire alarm.

Water entered an adjacent lane-services cabinet through its top cable aperture. The cabinet contained power supplies, network media converters and relay interfaces for six lanes. Protective devices operated after visible arcing at the lower terminal rail, isolating the cabinet and a section of car-park lighting.

The luggage shuttle stopped under the damaged pipe. Its passengers were moved through a pedestrian door, while standing water spread through the exit channels and toward the payment-terminal islands.

07:09 — Site evacuation and road closure

Airport operations treated the sprinkler flow and loss of lighting as a potential fire condition. Staff began clearing the multi-storey facility on foot and prevented further vehicles entering. Drivers already queued at the exits were instructed to switch off and leave their vehicles where safe.

Inbound parking traffic backed onto the terminal roundabout before attendants could establish a diversion. An airport bus and two hotel shuttles became trapped across the junction, obstructing access to the long-stay road. Police closed the approach and directed pre-booked customers toward off-airport facilities.

The public website continued accepting valid reservations because central capacity still reflected the last successful lane events. Sales were manually suspended at 07:14, after a further 186 bookings had been confirmed for facilities that could no longer accept vehicles.

07:18 — Emergency attendance

The fire brigade attended in response to the alarm and reported sprinkler discharge. Crews entered the multi-storey car park, confirmed that no fire was present and isolated the damaged branch once the affected areas had been checked. The building supply serving the flooded lane cabinet remained isolated.

Police and airport operations maintained the external road closure while vehicles were released from unaffected surface-car-park exits under local supervision. Recovery staff could not raise the multi-storey barriers electrically, and the route around the damaged shuttle and standing water was too narrow for ordinary traffic.

The original booking-platform support activity was suspended. Technical control passed to the airport incident team, fire-service liaison, highways representatives and the access-equipment maintainer.

10:35 — Controlled vehicle recovery

The mechanical master key arrived with the parking contractor. Barrier mechanisms were released by hand and arms removed where necessary. After the fire brigade and facilities team approved a dry route, vehicles were directed from the multi-storey facility one line at a time around the damaged lane.

The network loop was identified and the temporary patch lead removed. The flooded service cabinet remained disconnected. Controllers outside that cabinet returned when their service switches were restarted, but no automated command was issued until their full identifiers and direction profiles had been checked locally.

The last queued vehicle left shortly after 15:00. Airport approach roads returned to normal during the afternoon. The multi-storey car park remained closed to new arrivals, and affected customers were transferred or refunded.

Following day — Technical assessment

Post-incident findings

The booking platform performed its principal transaction and payment functions correctly. The initiating support action was taken to restore valid entry observations that had been rejected because of a controller clock discrepancy. Replaying those observations was a reasonable recovery objective.

The selected wildcard also matched actuator topics because the dead-letter exchange held all parking message families. Historical physical commands were not idempotent at the adapter and had no effective expiry after replay. Loss of the routing header then exposed a separate identifier-shortening condition in the vendor diagnostic integration.

Automatic reconciliation amplified the initial state changes by applying a complete but incorrect lane profile. Manual diagnostic access introduced a network loop because the service switches were already joined through an undocumented fibre path and did not participate in spanning tree. The subsequent vehicle, barrier and sprinkler events required the additional coincidence of retained controller state, a moving shuttle and the location of the sprinkler connection above the clearance assembly.

Corrective programme

Observation, entitlement and actuator messages were moved to separate exchanges with distinct dead-letter policies. Actuator commands received a short mandatory expiry, complete site key and adapter-side command identifier. Replay tooling was changed to show message families and reject physical commands unless a named lane and second approver were supplied.

Full controller identifiers replaced shortened diagnostic keys. Automatic configuration reconciliation was disabled pending vendor review, and every lane profile was exported and signed against its cabinet label. Service switches were added to the managed topology with loop protection, while spare diagnostic ports were restricted to one authenticated connection at a time.

Physical release keys were placed in two onsite break-glass cabinets outside the electronically controlled room. The replacement lane-services cabinet received a sealed top entry and was moved outside the sprinkler discharge path. Public capacity now freezes and online sales stop automatically when the site event age exceeds five minutes.

Final attribution

No single component independently accounted for the outcome. The incident required a carrier interruption, clock variance, shared dead-letter topology, wildcard replay, non-expiring commands, lost routing metadata, shortened vendor identifiers, automated profile reconciliation, an undocumented layer-two path, mixed controller fallback behaviour, unavailable manual keys, vehicle movement and an exposed sprinkler joint.

Each mechanism had operated successfully in its ordinary context and became material only after the preceding controls were exhausted. Responsibility was therefore distributed across application recovery, vendor integration, site networking, local key management, lane equipment and building-services placement, with no individual change regarded as solely determinative.