Content-Based Routing: Directing Traffic by Request Details
Content-based routing is a smart traffic cop for your services. It inspects request headers or URIs to direct traffic, enabling canary releases or A/B tests. The footgun is rule order: a broad rule placed first can shadow specific rules below it.
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.
Interview question
Which statement accurately describes a critical consideration when configuring content-based routing rules?
- a.Rules should be ordered from most specific to most general to ensure proper matching.Correct
- b.The system automatically optimizes rule order for performance, making explicit ordering unnecessary.
- c.Broad, catch-all rules should always be placed first to efficiently handle the majority of traffic.
- d.Routing rules are processed concurrently, so their defined order does not impact the final routing decision.
Why? this is the answer
Content-based routing rules are evaluated in order from top to bottom. Placing broad rules first can 'shadow' more specific rules below them, preventing them from ever being matched. Therefore, specific rules must precede general ones.
Just read this? Test yourself on what you have been reading.
Read the original → istio.io
- #istio
- #service mesh
- #traffic management
- #kubernetes
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles