Orchestration vs Choreography: A Guide to Composing Your Monolith

Microservices promise rapid evolution, operational independence, and technological freedom - but they come with imperceptible drag factors. Left unchecked, this drag leads to distributed balls of mud that are hard to operate, evolve, and maintain.

The question I kept coming back to while preparing this talk: how do our architectural decisions affect our ability to effect change? I’d seen teams at PokerStars and Sky Betting & Gaming wrestle with this constantly, and I wanted to dig into the patterns that seemed to make a real difference.

The talk explores system composition through two lenses. Orchestration gives you a single point managing workflow state - synchronous API calls, stronger coupling, but easier error handling when things go wrong. Choreography distributes coordination via message brokers, taking an event-driven approach with weaker coupling but more complex error management. Neither is universally better; the right choice depends on your context.

I spent a fair bit of time on Lehman’s Laws of Software Evolution, which I find genuinely useful for thinking about system maintenance. The relationship between change, complexity, and development velocity is something teams often feel but struggle to articulate. I also covered the practical stuff - event types, message patterns with AMQP and Kafka, delivery semantics, and why idempotency matters more than people initially expect.

One framework I introduced was thinking about six types of coupling: structural, control, data, domain, incidental, and organisational. Understanding these helps teams make better decisions about where to draw service boundaries.

This was my first time on the main stage at QCon San Francisco, which felt like a proper milestone. The audience questions afterwards were excellent - it’s clear this is a topic many teams are actively grappling with.