Shapes, not logos

The problem

An energy business takes in readings from metering devices in the field, continuously and at national scale. They arrive in whatever shape the source produces: loosely structured, several kinds of measurement mixed into one payload, and full of holes — a device that was offline, a network that dropped, a batch that turned up twice.

What I built

A single parse step turns each payload into typed streams — energy, power, voltage, peaks — so everything downstream works against a known shape instead of guessing at one. Missing intervals are interpolated against the meter's own history. The streams are rolled up as they pass: per day, per week, per month.

A separate branch watches for the two things a person actually needs to know about: a meter that has gone quiet for longer than its interval allows, and a reading that cannot be true.

What changed

The business stopped reasoning about files and started reasoning about readings. Aggregates that had been the output of an overnight job became continuous, and a meter going dark became something noticed in hours rather than at the end of a billing period.

The problem

Service technicians maintain lifting equipment on customer sites, often an hour's drive away. What they need in order to do the job lives in four different places: the machines, the rental contracts, the availability of parts, and the service requests coming in. Arriving without the right part means a second visit, and a second visit costs more than the part.

What I built

An application fed entirely by events from those four domains over Kafka and joined into one view of the job: which machine, under which contract, what is wrong with it, which parts it needs, and whether those parts are on hand. The technician works from that single view on site rather than from four systems before setting off.

What they do then goes back out as events — the service performed, the parts consumed — which the other domains pick up in turn.

What changed

The information a technician needed stopped being something they had to assemble, and what happened in the field stopped needing to be typed in a second time somewhere else.

The problem

Money collected for the use of music has to reach the people entitled to it: publishers, editors, composers and performers. The source data arrives as very large files whose records refer backwards to earlier records, so nothing can be handled on its own. And approximately right is not a category here — every share is somebody's income.

What I built

A parser that resolves those back references while streaming, rather than holding whole files in memory, and a distribution modelled as explicit steps rather than one long run: validate the input, establish the budget actually available to distribute, apply the shares, resolve outstanding debt claims, and follow inheritance so that money owed to someone who has died reaches whoever is entitled to it now.

What changed

Each step of the distribution became separately inspectable and separately explicable — which matters a great deal when "why did I receive this amount" is a question that has to have an answer.