Content-Based Routing: Directing Traffic by Request Details

WHY IT EXISTS As systems grow, simply sending traffic to a pool of identical servers isn't enough. You need finer control to test new features, migrate users gradually, or serve different experiences to different clients. Content-based routing was created to solve this by making the network aware of the application-level context of each request.

THE MENTAL MODEL Think of it as a smart mail sorter at a large company. A basic sorter just sends all mail to the company's address (the service). A content-based sorter opens the envelope to see who it's for. A letter for the CEO (a request from an internal user) goes to the executive suite (a new canary version), while a bill (a request from a payment bot) goes to the finance department (a stable version). Same destination address, different internal routing based on content.

HOW IT WORKS In a service mesh like Istio, you configure content-based routing using a resource, typically called a VirtualService. This resource defines a set of routing rules. Each rule has a 'match' condition and a 'route' action. The match condition inspects parts of the request, such as the URI path (e.g., '/api/v2'), specific headers (e.g., 'User-Agent: Android'), or cookies. If a request matches the condition, Istio's proxy directs it to the specified destination subset (e.g., the pods for service version 'v2'). Rules are evaluated in order, from top to bottom.

WHEN TO USE IT This is the go-to technique for several key patterns. First, canary releases: route a small percentage of traffic, or traffic from internal users, to a new version. Second, A/B testing: route users with a 'group: B' cookie to a new feature to compare its performance. Third, API versioning: route requests for '/api/v1' and '/api/v2' to different backend services from a single domain. Finally, device-specific routing: send requests from mobile user agents to a mobile-optimized backend.

WHEN NOT TO USE IT Avoid it for simple applications where basic load balancing is sufficient, as it adds configuration complexity. Be cautious of creating overly complex, multi-layered routing rules that become difficult to debug or reason about. Also, it's ineffective for routing based on encrypted request bodies, as the proxy cannot inspect the content.

ONE CANONICAL EXAMPLE In Istio's Bookinfo sample application, you can configure a VirtualService to route a specific user to a new version of the 'reviews' service. The rule would match a request where the 'end-user' header is 'jason' and route it to the 'reviews:v2' subset. All other users, not matching this specific header, would be routed to the default 'reviews:v1' subset. This allows 'jason' to see a new feature (black stars on reviews) while all other users see the stable version.