Java since 2005, event-driven since 2008. I build the ones your team can still run after I've gone.
See how I workHow I work
A system nobody can hold in their head gets cut into pieces small enough to build, demonstrate and put in front of people — in weeks, not quarters. The risky part goes first, while there is still time to be wrong about it.
Events are hard to reason about until you can see them. So I build the projections, views and small tools that make the system tangible — off-the-shelf where something fits, written from scratch where nothing does.
Runbooks, dashboards and alerts that name the problem instead of the metric. The measure of the work is what happens after I stop invoicing.
Selected work
Clients stay unnamed. The interesting part was never who they were.
Readings arrive continuously from devices in the field, in whatever shape the source hands them over. Parsed once, fanned out into typed streams, gaps interpolated against history, rolled up daily to monthly — and a human told when a meter goes quiet or sends something that can't be true.
Kafka · Spring · JavaTechnicians servicing lifting equipment on customer sites. Machines, rental contracts, parts availability and service requests each lived in their own system; events from all four became one view a technician could work from — what the job is, what it needs, what to bring. The work done went back out as events.
Kafka · Spring · JavaMoney owed to publishers, editors, composers and performers. The source data arrives as very large files whose records refer backwards to each other, so nothing can be handled in isolation — and the distribution itself runs from validation, through working out what budget is actually available, to debt claims and inheritance.
Java · SpringAbout
I'm Stijn Van Bael. Appify is my consultancy, based in Ruddervoorde. I've written Java professionally since 2005 and worked on event-driven systems since 2008 — usually the ones that already exist and have started to hurt.
The expensive problems are rarely the broker. They are the single clause in a requirements document that says the system must be able to replay from any point in time, which quietly decides most of the design. They are rebuilding one part of a system as event-driven while the rest carries on unchanged. They are a database transaction and a published event that must either both happen or neither.
Contact
A short description of the system and what it does when it misbehaves is enough to start. If it isn't a fit I'll say so, and usually say who would be.
