About
Java since 2005. Event-driven systems since 2008. One engagement at a time.
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.
I take one engagement at a time. That is a deliberate limit rather than a scaling problem: the work I'm good at needs enough of my attention to hold a whole system in view, and a consultant running three of those at once is doing none of them properly.
What tends to be hard
Three problems that show up again and again, and none of them is choosing a message queue.
A single sentence in a requirements document, easy to nod at in a meeting, and it decides most of the design. What you keep, how long you keep it, whether a consumer can be run twice without doing damage, and what "the state as of last Tuesday" even means.
The rest of it has to carry on working while one piece is replaced with an event-driven version, and both have to stay correct for as long as that takes — which is longer than anyone plans for. Strangling a system out is mostly a question of where you cut and what you are prepared to write twice.
Either both happen or neither should, and there is no transaction spanning the two. Every answer to this is a trade — of latency, of duplicates, of complexity somewhere else — and picking the right one depends on what the business does when it goes wrong, not on what the diagram looks like.
How 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. A team that can see what the system is doing makes better decisions about it than I can make for them.
Runbooks, dashboards and alerts that name the problem instead of the metric. The measure of the work is what happens after I stop invoicing — so I'd rather leave a team able to run the thing than leave them a dependency on me.
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.
