Ingest
Services pulling market and operational data on their own schedules, with gap detection and re-fetch for anything missed during an outage. Nothing downstream ever sees a vendor format directly.
Work
One system, described the way an engineer would want it described.
The method is domain-agnostic — the same architecture works for logistics, industry, fintech or anything else that has outgrown a spreadsheet. What follows is what it looks like applied to energy-market trading analytics.
In development
Energy-market trading analytics — hodie.cz & elrnd.com
A platform that continuously ingests energy market and operational data, computes curves, signals and forecasts over it, and delivers the result to the people who trade on it — in the tools they already work in.
- Role
- End to endQuestions, stack, architecture, build, cluster, operations
- Runtime
- KubernetesMulti-host cluster, described in code
- Architecture
- MicroservicesSmall parts, versioned contracts
- Status
- ActiveUnder development, iterating with the client
The problem
Analytical products of this kind usually start as research: a script that pulls data, a spreadsheet that computes something useful, a report sent round by mail. That is the right way to start, and it works until the thing has to run every day and be trusted with money.
At that point the same three failures appear every time. Nobody can reproduce yesterday's number. Every change touches everything else, so changes stop happening. And the answer arrives in a place the people who need it do not look.
The approach
We started with the questions rather than a specification: where each number comes from, who corrects it by hand, how bad late is, how bad wrong is, and where the people who act on it actually are during the day.
Those answers decided the stack — above all the storage, chosen for this data shape — and from there the system is a set of small services on Kubernetes, each with one job and a versioned contract, connected by an explicit data flow.
The +n argument, in practice
What changed in the last quarter
A forecasting service and a chat notifier were added months after the first release, and one early service was removed once its job turned out to belong somewhere else. None of it required touching the parts already running, and no contract broke.
That is the entire claim on the home page, stated as an event rather than a diagram: the cost of the fourteenth service was the cost of the fourth.
- Added: forecasting — a new model service reading the existing feature flow, deployed without a release train.
- Added: chat delivery — results pushed into the tools the team already lives in, rather than a dashboard they have to remember to open.
- Removed: one early service — deleted cleanly once its responsibility moved, subtracting exactly what it had cost.
- Broken contracts: none — producer and consumer are verified against the schema on every build.
- Client
- hodie.cz · elrnd.com
- Market
- Energy
- Domain
- Trading analytics
- Engagement
- Build the system
- Languages
- Go · Python · TypeScript
- Runtime
- Kubernetes
- Delivery
- GitOps, IaC
The system, layer by layer
Normalisation
One canonical model for instruments, events and time, with schema validation that alarms when a source quietly changes format — the failure that otherwise goes unnoticed for days.
Storage
Chosen for this data specifically: long windows for research and narrow recent windows for the live view, with a clear line between what can be recomputed and what must never be lost.
Compute
Curves, indicators, signals and our own models — trained and predicting on the live stream — as separate services: Go where throughput matters, Python where the models live, each scaled on its own load. New computations arrive as new services, not as edits to existing ones.
Delivery
The analytics interface for the people who want to look, and chat delivery for the people who want to be told — with every figure traceable back to the records that produced it.
Platform
Kubernetes underneath all of it: deployments for the steady stream, jobs and job pipelines for periodic work, metrics and logs from the platform, environments defined in code.
Where this transfers
The domain is an example. The engineering is the offer.
Streaming data, scheduled pipelines, computation that must be reproducible, models under supervision, answers delivered where people work — energy trading needs all of it, and so do a lot of industries that would never call themselves technical.
Energy & commodities
- curve & price data
- forecasting
- position analytics
Trading & fintech
- signal platforms
- real-time ledgers
- anomaly detection
Industry & IoT
- telemetry at scale
- predictive maintenance
- edge to cluster
Logistics & operations
- planning systems
- event tracking
- internal tooling
Research to production
Turning a working spreadsheet or research codebase into a system that runs every day, reproducibly and safely — without discarding the work that proved the idea.
Past the wall
A system that has become too entangled to change, restructured into parts that can be added to and removed from again.
Platform rescue
Inheriting a cluster nobody fully understands and making it legible, cheaper and safe to deploy to.
Want the same treatment for your system?
Describe the business, not the technology. If we are not the right people for it, we will say so — and usually point you at who is.