Designing an event-driven architecture is more than thinking about services and message flows. All those decisions need to be implemented in the topology of the system: the queues, topics, subscriptions, and routing rules that make up our running system. Making these decisions isn't trivial... How many message types comfortably fit onto a single queue? Should you have a topic per event type, or is mixing several event types a better approach? And what about filtering and routing? These are the questions you'll wrestle with from day one… And every day after.

There's a fallacy in distributed computing, that the topology will never change… And like all the others, it's a lie we tell ourselves to sleep at night. When traffic shifts, queues start choking, consumers overuse filtering causing more latency, and breaking changes to event types threaten to ripple through every subscriber and break half the system. In this session, we'll tackle both sides of the topology problem: the initial design decisions and the techniques to redesign when reality catches up us. We'll dig into the signals that show it's time for a split and how to go about it -without- losing messages along the way, with practical examples in Azure Service Bus. By the end, you'll know how to make well-balanced topology decisions — and accept that the topology you have today won't necessarily be the one your system needs tomorrow.