Why a mobile parking search app loses data
A mobile parking search app breaks not on the map, but on the freshness of the status mark. A sensor registers a spot as occupied — the event reaches the screen through a chain: the site gateway, message queue, aggregate recalculation, delivery cache.
If delay accumulates at any step, the driver sees a green marker where a car has already been parked for ten minutes. He wastes fuel and time on a detour, arrives — and leaves for a competitor whose mark arrived earlier.
For the driver, this is not a rounding error but a broken promise, and in reviews he sums it up briefly: occupancy status does not update.
Worse, the failure is self-sustaining. Outdated parking data keeps traffic directed to occupied spots: the app again and again sends new drivers there, they park in unauthorized places, block exits, call the hotline.
Support drowns in identical requests for exactly the same addresses, while the team, instead of development, fixes the symptom — manually removes marks and edits the polling schedule.
Meanwhile, the driver cannot find a free spot two blocks from the destination, although one exists there: it simply did not make it into the snapshot.
The root cause is the absence of an honest data contract: it is unknown where the event came from, when it happened, after how many seconds it must be re-requested, and what to show the driver if the site is silent. Hence ghost marks and disrupted search.
We break down how this is closed: the shelf life of a mark, confirmation upon actual entry, degradation instead of silence, and a metric showing that search works again.
What changes after implementing live occupancy data
While site occupancy is updated once a day or manually by an operator, the app shows the past: the driver arrives at a jammed entrance and leaves for a competitor.
Live data changes the very logic of the suggestion — the stream from sensors, barriers, and city operators is aggregated into a geo index and goes to the app with a delay of seconds. Here is what becomes measurable after this:
- Share of empty arrivals — trips that end with a U-turn at an occupied site — falls by 2–3 times; this is the first metric that shows the effect.
- Reaction time to changing conditions: the suggestion no longer waits for an operator and nightly table synchronization — the map layer is rebuilt on the event.
- Frequency of repeat support requests shifts: complaints like "the map shows free, but the entrance is closed" leave the flow, leaving isolated cases with broken sensors.
- A whole class of failures goes away: cache divergence from actual state, manual reconciliations, "stuck" statuses after a data source outage.
- Driver retention grows due to predictability — those whose suggestion worked three times in a row come back.
We verify this not by eye. The navigation layer on Mapbox returns events with timestamps, so the "before" and "after" states are calculated for the same site at the same hours — removing seasonality and weather from the measurement.
Comparison of approaches: data acquisition modes and their limitations
The freshness of occupancy data determines whether the driver will trust the app after a second miss.
Choosing a source is always a trade-off between update frequency, coverage area, and maintenance complexity: one option gives accuracy at a dozen sites, another gives an approximate picture across the whole city.
| Option | When it fits | Where it breaks |
|---|---|---|
| Own entry sensors | The site is under our control, accuracy down to one car is needed | Installation and maintenance at every point, coverage grows slowly |
| Stream from a parking operator | The partner has its own accounting system and open data exchange | Dependence on someone else's failure, we do not control update delay |
| Scheduled batch export | Tariffs, rules, zone boundaries, address directories | The snapshot becomes outdated within hours and is unsuitable for real-time occupancy |
| On-device cache | Weak connection, underground levels, repeated app opens | Shows the last known state, an honest "data as of" label is needed |
The working scheme is a hybrid: streaming updates where the partner provides them, periodic polling as a fallback, and a time-stamped cache on the device itself.
This way the app remains useful when the connection drops, instead of showing an empty screen at the most needed moment.
How implementation proceeds: stages of engineering work
We build the stages of implementing a parking search service from data, not from screens: without a robust data exchange scheme, the interface shows yesterday's picture. This order of work allows launching in a limited area and expanding without rewriting the core.
- Service and source audit. We analyze which sites already provide occupancy data, with what delay, where counters diverge from the actual picture, and which areas will have to be covered by forecasting or manual input.
- Data exchange scheme. We fix the contract: response format, update frequency, cache of last known values, retries, and behavior when the source is unavailable. This determines what the driver will see when the connection drops.
- Scenarios and app skeleton. Search, spot card, route, booking. We design states separately: loading, no data, a spot was taken a minute before arrival.
- Integration and free-spot logic. We consolidate streams, add occupancy forecasting and a confidence threshold: if there is no data, the app marks it as outdated rather than drawing false confidence.
- Testing on real traffic. A pilot in one district: we compare readings with actual occupancy, measure the share of discrepancies and response time during peak hours.
- Resilience and observability. We check peak requests, duplicate calls, and external source failures; we set up alerts so that we see degradation, not drivers.
- Project handover. We hand over code, configurations, access, the data exchange scheme, and documentation, and train the customer's team. After that, the service is developed by the customer's team or remains with us for support.
Composition of documentation and settings to be handed over
We hand over not an archive of files but a working system: so that the support team can update a data source, connect a new parking lot, or roll back a build without exchanging messages with us.
Below is the composition of the settings and documentation to be handed over, which we record in an act.
- Environment configurations: build parameters, addresses of occupancy data sources, separate sets of variables for the test and production environments — switching without code changes.
- Integration schemes: how the app receives data from parking operators, the mapping service, and the payment gateway, with response formats and behavior when the source is unavailable.
- Data access policies: service account roles, key lifetimes, separation of personal and anonymized trip data.
- Data update regulations: frequency of polling sources, validity window for price and spot status, procedure for connecting a new parking lot.
- Support instructions: analysis of typical failures — source is silent, coordinates are outside the coverage area, price diverges from actual payment.
- Monitoring scheme: which metrics we collect, trigger thresholds, who receives the alert, and in what order to act.
- Rights transfer: repositories, build registry, monitoring dashboards, accounts in app stores.
| Documentation format | When it fits | Limitations |
|---|---|---|
| In the repository next to the code | support works in the same repository | edits are available only to those with permissions |
| In an external knowledge base | multiple contractors, support service without code access | diverges from code without a synchronization regulation |
| Combined | typical case: configs and schemes — in the repository, instructions — in the knowledge base | a person responsible for synchronization is needed |
The formats do not replace each other: it is important that by the time of handover it is clear where the current version of each artifact is located.
Case study: removed false occupancy statuses at city parking lots
The parking search service collects data from three independent sources: stationary sensors in the pavement, entry cameras, and marks from drivers themselves.
The failure was not in coverage but in desynchronization — the sensor reports "occupied", the car has already left, and the next driver circles the block looking at an outdated mark.
In this parking search case, half of support requests boiled down to one phrase: "the map shows free, but it is actually occupied."
What we changed
We introduced the concept of confidence for each cell: equipment readings live for a limited time and require confirmation, while driver marks do not overwrite sensor data but only lower confidence.
Disputed spots go into a separate queue for rechecking, and the exit camera closes the loop when a car has actually freed the spot. We separately reworked offline mode: the app shows not the last received status but the age of that status, so the driver understands what to trust.
What resulted
The share of false occupancy statuses decreased from 24% to 3–5% and has held at that level for a second season, including morning and evening peak hours.
Support requests on the topic of "no space" fell by about four times, and the share of trips that ended with actual parking at the chosen spot tripled.
City parking operator received a predictable district-level occupancy picture — it is used when revising tariff zones and inspector work schedules.
How does a live parking occupancy data stream differ from polling?
Polling — the app asks the server on a timer: "how many spots are free at this parking lot right now?".
The status update frequency here is a direct trade-off: infrequent polling — the driver arrives at an already occupied spot; frequent polling — the app drains the battery faster, and the service gets an avalanche of identical requests.
The reliability of occupancy data is capped by this interval: between two requests you know nothing.
A live stream flips the scheme: the connection is maintained continuously, and the server itself sends an update at the moment when a sensor or barrier records entry or exit.
The delay between the event and the number on the screen falls from tens of seconds to single digits, and an update arrives only when the status has actually changed — an empty parking lot stays silent and does not consume traffic.
A connection drop behaves differently. With polling, the next attempt restores the picture on its own, so the interface is at most delayed.
With streaming, it is important not to leave outdated occupancy on the screen: the client must resubscribe and immediately request a full state snapshot, otherwise the driver sees a free spot that is already gone.
We pull the parking layout and addresses from OpenStreetMap, and occupancy from city gateways and sensors.
The cost of ownership also diverges. Polling pays for a uniform request flow around the clock, including at night and in residential districts where nothing changes. Streaming pays proportionally to the number of real events, but requires a stable connection on every client.
Therefore, in city environments we assemble a hybrid: streaming for active zones, a rare state snapshot as insurance and as a source of truth after a failure.
Common technical questions about integration
Integration with parking lots is rarely uniform: each operator has its own way of providing occupancy data, its own fleet of entry equipment, and its own access rules for them.
Therefore, the conversation almost always comes down to four technical concerns — what to do if the source is unavailable, how to connect to old barriers, how accurate the spot status is, and how to handle driver data. Below are short answers that usually resolve these questions at the start.
The resilience of the solution is built not on one source but on several at once: operator polling, data from our own entry equipment, and a backup manual mode.
If one channel responds with a delay or fails, the app determines the status from the others and honestly shows the last update time instead of an outdated number.
The parking lot has no software interface — only cameras and an operator. Is that a workable option?
Yes. We collect data from recognition cameras at entry and exit: we calculate status as the difference between entries and exits.
If there is no equipment at all, the site is connected in manual confirmation mode — the operator marks occupancy, and the app synchronizes it with periodic reconciliation.
Will connecting to old barriers disrupt their current operation?
We work in read-only mode and do not interfere with the opening logic: we take only passage events, while control remains with the existing system.
Connection proceeds site by site, during off-peak hours, preserving the previous scheme — if something goes wrong, the site returns to its original state without stopping entry.
How accurate will the "has free spots" status be?
Accuracy is limited by the quality of the source, so we do not show false specificity. Where a counter calculates the difference in passages, error accumulates — it is suppressed by regular reconciliation with actual occupancy.
In the interface, the driver sees a gradation of "free / few / occupied" and the update time, and a booked spot is confirmed by the fact of passage.
What driver data is stored, and who has access to it?
Vehicle number and geolocation are personal data, so we store the minimum necessary for the service to operate: we anonymize history for analytics, encrypt transmission and storage, and restrict access by roles with an action log.
The storage period is limited, deletion is performed at the driver's request, and the processing scheme is coordinated with local legal requirements before launch.
Where to start: what we will discuss at the first meeting
The first meeting is needed not for a presentation but for analyzing input data.
For a parking search service with real-time data, the most important thing is to understand where information about spot occupancy comes from and how much it can be trusted — both the architecture and the app scenarios depend on this.
What helps discuss the task concretely:
- Geography and parking types. Cities and districts of the first launch, on-street, enclosed, and park-and-ride lots — this determines how many data sources must be connected immediately.
- Occupancy data sources. Who owns the information: operators, access systems, on-site sensors, manual updates. What is already provided machine-to-machine, and what will have to be collected and brought to a unified form.
- Update accuracy and delay. Acceptable error, data staleness time, app behavior when the source drops: show the last known, mark as inaccurate, or switch to manual search.
- User scenarios. Search on the map, booking, payment and extension, route to the spot, cancellation — what is mandatory in the first version and what can be postponed.
- Peak load. Morning hours and events near the site: how many updates arrive simultaneously and how the service withstands it.
- Payment and restrictions. Who accepts payments, whether refunds are needed, what personal data requirements apply in your region.
- What already exists. Existing apps, accounting systems, analytics, and roles in the customer's team.
After the meeting, we return with an estimate and a stage plan: what we do first, what can be launched earlier, and where the data risks are. For the calculation, a source scheme, sample exports, and a description of scenarios are enough — we will clarify the rest as we go.