Dynamic Router

A content-based router has fixed rules: "international orders go here, domestic orders go there." If you need to add a new destination, say, a new warehouse in Canada, you redeploy the router code.

A dynamic router adapts its routing rules at runtime, without redeployment. New participants register themselves with the router. Routing tables update automatically. Routes change based on load, availability, or configuration changes.

Think of a GPS navigation system. It doesn't have hardcoded routes. It discovers road conditions in real time and adjusts. New roads are added to the map. Closed roads are removed. Traffic patterns shift the optimal route. The GPS dynamically computes the best path every time.

Dynamic routing is where content-based routing meets runtime configuration. It's the pattern that makes these real-world systems possible:

• Multi-tenant SaaS: Each tenant gets its own processing queue. New tenants onboard without code changes. Shopify routes merchant webhook events through a dynamic router that maps merchant IDs to processing queues, no deploys needed when a new merchant signs up.
• A/B testing: 10% of messages route to a new processing pipeline. The percentage adjusts via a config flag. LaunchDarkly and Split.io both use dynamic routing internally to direct feature flag evaluations to different backend clusters.
• Canary deployments: Traffic gradually shifts from the old service to the new one. 1%, then 5%, then 25%, then 100%. If error rates spike, the route reverts to the old service in seconds.
• Geographic routing: Messages route to the nearest data center. When a DC goes down, its routes shift to the next closest region.

The dynamic router maintains a routing table that can be updated at runtime:

class DynamicRouter {
 private routingTable: Map<string, string> = new Map();
 
 // Services register themselves
 registerRoute(messageType: string, destination: string) {
 this.routingTable.set(messageType, destination);
 }
 
 // Services deregister when shutting down
 removeRoute(messageType: string) {
 this.routingTable.delete(messageType);
 }
 
 route(message: Message): string {
 const destination = this.routingTable.get(message.type);
 if (!destination) throw new Error(`No route for: ${message.type}`);
 return destination;
 }
}

Dynamic rule sources:

Real-world example: A multi-tenant SaaS platform routes messages by tenant ID. New tenants are provisioned with their own processing queue. The dynamic router reads the tenant-to-queue mapping from a configuration store. When a new tenant signs up, the provisioning service adds a routing entry, no router redeployment needed.

HashiCorp Consul's key-value store is a popular backing store for dynamic routing tables. The router watches a key prefix (e.g., routing/tenants/) and reloads its in-memory table whenever a key changes. Consul's blocking queries provide near-real-time notification of changes without polling.