TRAFFIC ENGINEERING
Traffic steering is a service decision.
A route can be valid while the experience behind it is poor. Start with the service you need to deliver.
Start with the destination
Traffic engineering is often described through its controls: routing policy, path selection and the distribution of load. Those controls matter, but they are easier to evaluate once the service objective is clear. What should the user experience, and which constraints must the network respect?
Reachable is only the beginning
Anycast can make the same service address available at several locations. The routing system selects a path; it does not automatically know which application instance has spare capacity or the shortest queue. A change that improves network latency can still send more work to an already busy service. Reachability and application readiness need to be considered together.
Make the decision observable
A useful steering change starts with a prediction: which traffic should move, where it should go, and what should improve. Pair network observations with service measurements. Watch errors and latency as well as traffic volume. Keep a comparison period, identify a rollback condition and check whether the receiving location has room for the additional demand.
Judge the result at the service boundary
Consider a hypothetical region that has a shorter network path but less available serving capacity. Moving every request there may be a poor trade. The right decision depends on the full path to a useful response. That is the perspective I want traffic engineering to retain: routing changes are operational decisions with consequences for the service.