Traffic Routing
Applies to every DynamoAI product. Probe endpoints are DynamoGuard specific.
Requests reach the active region through a global load balancer that health-probes both regions and removes an unhealthy region from rotation.
Probe Settings
Probe the regional deployment as a whole. A probe aimed at a single component can withdraw a region for a fault confined to one service, and can leave a single request path spanning both regions.
| Setting | Value |
|---|---|
| Probe target | See Probe Endpoints. The endpoint you choose decides which dependencies a passing probe covers |
| Probe interval | 30 seconds. Set this explicitly; provider defaults are much longer |
| Healthy response | 200. Treat every other status as a failure |
| Evaluation window | Several consecutive samples, so one slow response does not withdraw a healthy region |
| Failure action | Remove the whole regional deployment from rotation |
Probe Endpoints
The API exposes four health endpoints and they do not cover the same dependencies. Which one the load balancer probes decides what a passing probe actually proves about the region.
| Endpoint | Dependencies checked | Establishes |
|---|---|---|
/health | None. Returns a static response | The process is listening |
/health/live | None. Runs an empty check list | Liveness only |
/health/ready | MongoDB, application PostgreSQL, Keycloak PostgreSQL, Keycloak | Readiness for platform traffic |
/health/status | The four above, plus Redis, Flower, moderation, S3 and data processing | Full dependency status |
/health/ready does not check moderation, and it does not check Redis, S3 or data
processing either. A region whose guardrail path is degraded still answers /health/ready
with a 200 and stays in load balancer rotation.
Startup applies the same split. The API exits only when MongoDB, either PostgreSQL, or Keycloak is unhealthy. It logs an error and starts anyway when Redis, S3, moderation or data processing is unhealthy, and logs a warning for Flower.
Probe /health/status if withdrawal should follow guardrail health. The tradeoff is that any
one of nine dependencies can then withdraw the region, including Flower.
Withdrawal takes the probe interval multiplied by the sample count, plus DNS propagation. Both terms are within your control and both belong in the recovery time budget.
What A Probe Establishes
A probe that performs a moderation request confirms that the region is reachable and that one policy is loaded.
A request naming a policy the region does not hold returns a normal success with fewer checks applied. A standby whose configuration is reachable but stale therefore answers probes normally while enforcing less than the primary did. No endpoint reports policy parity in the current release, so compare the policy list between regions as an operator step before cutover.
Cutover
- Confirm the primary region is unavailable. A partially available primary risks divergent writes once the replicas are promoted.
- Promote the datastore replicas. See Data Replication.
- Compare the policy list in the standby against the primary's last known state.
- Scale the standby to full capacity and confirm each guardrail policy reaches a ready state.
- Update DNS or the routing layer to the standby.
- Confirm moderation requests succeed.
The full procedure, including what does not fail over, is in Disaster Recovery.
Failback
Failback is a scheduled change. A recovered region can pass a health probe while its write path is still stale. Return it to service only after data written to the standby has been reconciled and replication runs in the intended direction.