Reflecting on a year of writing about Java, Betfair trading systems, and software architecture — what resonated, what I got wrong, and what's ahead.
A year ago I started writing here as a way to think in public. I’d been building Java systems professionally for over two decades, and the ideas I was working through at the bench — on Betfair trading strategies, on cloud architecture at scale, on patterns I’d picked up across investment banking, fintech, and government — weren’t going anywhere. The blog was an attempt to get them out of my head and into a form that might be useful to someone else.
A year on, it feels worth pausing and taking stock. What actually resonated with people, what I was wrong about, what I’d do differently, and what I’m most looking forward to writing about next.
I won’t pretend otherwise — the Betfair posts consistently top the search traffic and the contact form submissions. When I wrote the first one (a getting-started guide to the Betfair Exchange API) I wasn’t sure if it would find an audience, because the intersection of “serious Java engineers” and “automated betting exchange trading” feels niche. It turned out the intersection is more populated than I thought, and significantly underserved in terms of useful technical content.
Most of what you find when you search for Betfair API development is either superficial — copy the authentication code, you’re done — or locked away in paid Discord servers and closed forums. There’s a gap for honest, detailed, production-level technical writing on the subject, and I’ve tried to fill it. The Weight of Money post, the Streaming API deep-dive, the ladder depth analysis — these have all found readers who are genuinely building things and want to understand the system at a level that lets them make better engineering decisions.
The in-play trading post this week is one of the most technically specific things I’ve written, because in-play automation is where the gap between “working code” and “production-safe code” is largest. The fact that it requires real survival logic — kill switches, emergency hedging, suspension handling — is something most introductory material completely glosses over.
I wrote about idempotency early in the series and I oversimplified it. The post was accurate as far as it went — use idempotency keys, make your POST endpoints idempotent, store the key and response so retries get the same answer. All correct.
What I didn’t cover well enough was the interaction between idempotency and distributed transactions, particularly in the context of Betfair order placement. The assumption I made — that idempotency was a property of the endpoint, fully separable from the surrounding transaction management — is too clean. In practice, the question of “what does it mean to retry this operation” is entangled with compensating transactions, order state reconciliation, and the specific semantics of whether your backing exchange has processed the request or not.
I’ve since written more carefully about the transactional outbox pattern and the Saga pattern, which are the correct tools for distributed transaction correctness. If you read the original idempotency post, treat it as a foundation and read those follow-ups alongside it.
More code, sooner. The posts that I’m proudest of — the architecture posts, the twelve-factor walkthrough, the DDD piece — are heavy on prose and somewhat lighter on code than the Betfair trading posts. I think that’s a mistake. The engineering posts that I find most useful, as a reader, are the ones where I can look at the code and see immediately whether the approach is applicable to my situation. Abstract principles without concrete implementation leave too much to imagination.
I’d also have introduced a clearer taxonomy earlier. The categories I use now — Betfair, Architecture, AWS, DevOps — emerged organically, but looking back at the first few months there’s a mismatch between what the posts are about and how they’re labelled. Nothing I can easily fix retroactively without breaking URLs, but worth noting for anyone starting a technical blog: decide on your taxonomy on day one, even if you don’t fill all the categories immediately.
I’m genuinely excited about a few topics that I haven’t written about yet.
Java performance at scale — I’ve been doing more Java Flight Recorder and JMC profiling work lately, both on the Betfair framework and on commercial contracts, and the tooling has improved dramatically. There’s a series worth writing on what JFR actually shows you, how to interpret the output, and the patterns that reliably indicate performance problems.
Multi-exchange architecture — running strategies across Betfair, Betdaq, and Smarkets simultaneously introduces interesting engineering problems around position reconciliation, market correlation, and arbitrage detection. The individual exchange integration posts are there; the “how to run them together” post is the next logical step.
AI tooling in professional Java development — I’ve been using Claude Code as a development assistant for several months. I have some honest and specific thoughts about where it adds genuine value (code exploration, refactoring, writing boilerplate for patterns you already understand), where it actively misleads (anything involving subtle concurrency or exchange-specific behaviour it hasn’t encountered), and how to calibrate your trust in it. That’s a post worth writing carefully.
Writing regularly has made me a more precise thinker. The discipline of explaining a system clearly enough for a reader who doesn’t have the context I have forces a kind of clarity that thinking-in-your-head doesn’t. Several times I’ve started drafting a post and discovered, halfway through, that I don’t actually understand the thing I’m trying to explain as well as I thought. The draft becomes the research.
If you’re a senior engineer who doesn’t write regularly, I’d recommend it. Not necessarily publicly, although public accountability does help with consistency — even a private technical journal forces the same discipline.
Twenty years of Java, a year of writing about it publicly, and I feel like I’m just getting started on both. There’s more to say and more to build. If you’re working on something in the Java, Spring Boot, or Betfair exchange space and want to compare notes, or if you’re building something that needs this kind of experience behind it, get in touch.