Skip to content
Zowork
All case studies
Case study~9 min read

A real-time logistics grid that renders 30,000 live rows.

A legacy desktop tool ran a logistics operation: hundreds of vehicles, thousands of records, constant change. We rebuilt it as a cloud web app without losing the density operators relied on. Thousands of records in one high-performance grid, and the live position of every vehicle on a map, updating in real time.

Web ModernizationReal-timeData-dense UILogistics
fleet.grid30,000 rows
vehiclerouteetastatus
VH-0142DE-7 · Hub 309:14en route
VH-0188DE-2 · Hub 109:22en route
VH-0203NL-4 · Hub 509:31loading
VH-0231DE-9 · Hub 209:40en route
VH-0274FR-1 · Hub 409:48delayed
VH-0299DE-5 · Hub 309:57en route
VH-0312BE-3 · Hub 610:05idle
rendered 120 / 30,000
virtualized · local data
Introduction

A desktop-grade tool, rebuilt for the browser

The client is a European logistics-technology provider whose software helps companies cut time, distance, cost and carbon across the logistics chain. Their operational tool was a legacy desktop application: fast and dense, but stuck on the desktop.

The brief was to bring it to the cloud as a modern web app without giving up what made the desktop version useful: the ability to render thousands of records from hundreds of vehicles in one high-performance grid, and to show their real-time locations and routes on an interactive map.

The brief

Four hard requirements

Each one is reasonable alone. Together, in a browser, in real time, they force real engineering.

A 30,000-row data grid

Filtering, sorting, grouping, aggregation, pagination, editing and resizing, across multiple tables.

Real-time updates

Reflect every change a driver makes on their device in the grid as it happens.

Interactive live maps

Plot the live locations and chosen routes of hundreds of vehicles on a map.

High performance

Keep the backend quiet and the experience instant, even under heavy load.

The hard problem

30,000 rows can't all live on screen

Draw 30,000 rows at once and the browser falls over. Draw only a page at a time and your filtering, sorting and totals go wrong. Operators needed both.

The answer was to separate what’s drawn from what exists. Only the rows actually visible on screen (roughly a hundred at a time) are ever rendered, so scrolling stays perfectly smooth. But the full dataset stays at hand in the browser, so filtering, sorting, grouping and totals are computed across all 30,000 records, not just the visible slice. The grid feels desktop-fast, and the numbers are always right.

Keeping the data close has a second payoff: the app barely talks to the servers. Instead of a round-trip for every scroll and filter, the data loads once and every interaction after that is instant and local.

The naive approachWhat we built
Backend requestsOn every scroll and filterOnce, then served locally
Filter / sort / groupA round-trip to the serverInstant, across all 30,000 rows
ConsistencyOnly the visible pageThe full dataset, always
The payoff
Minimal data requests, maximal responsiveness. With the data already local, every interaction (and every real-time update) is instant.
Real-time

Hundreds of events a minute, one source of truth

Drivers change state constantly. Every one of those changes had to land in every grid and the map, instantly and consistently.

Every event from the field flows into the same local data the grids read from, so the grids and the map are never out of step: they all re-derive from one source of truth. That design comfortably absorbs hundreds of events a minute and reflects them instantly across multiple grids holding vast amounts of data, without hammering the backend.

Driver event
from the field
Live channel
~hundreds/min
One local source
updated in place
Derived views
no refetch
Grids + map
updated in lockstep
Interactive maps

Hundreds of vehicles, moving live

The grid tells you what's happening; the map shows you where.

The map plots the live locations and chosen routes of hundreds of vehicles, driven by the very same event stream and local data that feed the grids. Markers move as the events arrive, so the map and the grids are always telling the same story: a super-fast, real-time, highly interactive application.

Migration

Teaching the old system to speak to the new one

Modernization rarely happens in one clean cut. The old and new worlds have to coexist.

To keep both worlds honest during the transition, we built a bridge that feeds the legacy system’s events into the modern web app’s real-time pipeline. The old desktop system and the new web app stay in sync during and after the migration, letting the client move with confidence rather than in a single risky leap.

Outcome

Desktop density, browser reach, real-time everything

30,000

Records per grid, rendered without a stutter

300+

Real-time vehicle events a minute, reflected across every grid and the map

1

Source of truth feeding every grid and the map

  • A super-fast, real-time, interactive web app replacing a legacy desktop tool.
  • Thousands of records rendered smoothly, with every interaction instant and local.
  • Live maps and grids in lockstep, driven by one event stream.
  • A guided deployment with full quality assurance, in partnership with the client.
Conclusion

Put the data where the work happens

The unlock wasn’t a faster grid. It was moving the data to where the work happens. With the full dataset kept close to the user, smooth rendering, real-time updates and live maps all became local operations: fast, consistent, and quiet on the network. A legacy desktop tool became a modern, real-time web app without losing an ounce of its density.

Got a data-dense, real-time app that needs to feel instant in the browser? We’ve done it at scale.

Talk to engineering