Skip to main content
All right — let’s jump into prepared queries. Prepared queries provide richer, latency-aware service discovery than relying on DNS alone. DNS is simple and widely supported, but it lacks the flexibility required for multi-datacenter or multi-cloud deployments. Prepared queries let you encode search order, latency preference, and deterministic failover behavior so clients automatically discover the best available service endpoints. What prepared queries solve
  • Control which datacenters are considered for a service lookup.
  • Prefer endpoints with the lowest round-trip time (RTT).
  • Implement hybrid fallback rules (latency preference plus deterministic fallbacks).
  • Make multi-cloud and multi-datacenter discovery predictable and resilient.
Previously, you could resolve a service with plain DNS — this is straightforward and works for simple deployments. When you need to control datacenter selection or implement latency-aware failover, prepared queries are the right tool. Failover policy types Below are the common failover policy types you can attach to a prepared query:
  • Static failover policy — specify an ordered list of datacenters to try.
  • Dynamic failover policy — prefer the N nearest datacenters by latency (NearestN).
  • Hybrid failover policy — combine nearest-N latency selection with an ordered static fallback list.
Examples Example: static failover policy
Explanation: If the local datacenter does not have a healthy instance of web-app, try dc2 first, then dc3 as deterministic fallbacks. Example: dynamic failover policy (nearest N)
Explanation: If the service isn’t available locally, query the two datacenters with the lowest RTT and prefer instances from them. Example: hybrid failover policy (nearest N + static list)
Explanation: First prefer the two nearest datacenters by latency. If those attempts fail, fall back to the static ordered list: dc2, then dc3. Choosing between policies
  • Static failover: simple, deterministic, good for small or stable environments with fixed datacenters.
  • Dynamic failover: useful when datacenter availability changes frequently (for example, ephemeral environments) and you want low-latency sources prioritized.
  • Hybrid failover: combine latency preference with deterministic fallback behavior for predictable resilience.
Important behavior of hybrid failover Each datacenter is queried at most once during a failover cycle. If a datacenter (for example, dc2) is included in the nearest-N selection, it won’t be re-queried again during the static fallback list. The static fallback excludes any datacenters already attempted as part of the nearest-N selection.
Use static failover for small, stable deployments. Choose dynamic or hybrid failover when datacenters are ephemeral or when you want latency-aware selection with deterministic fallbacks.
Comparison: DNS vs Prepared Queries vs Prepared Queries with Failover Links and references Summary
  • DNS is simple and broadly supported but not sufficient for advanced multi-datacenter routing.
  • Prepared queries add dynamic selection and richer discovery behavior inside a region or datacenter.
  • Prepared queries with failover policies are the ideal solution for multi-cloud and multi-datacenter applications where you need latency-awareness plus controlled fallbacks.
A dark infographic titled "Compare Options for Querying Services" shows three colored arrows labeled DNS, Prepared Query, and Failover Policy with short descriptions beside each. DNS is "Simple, but Not Flexible"; Prepared Query is "Dynamic, but Local"; Failover Policy is "Ideal Solution for Multi-Cloud Apps."

Watch Video