Three ways this can go wrong
"High availability" isn't one property — it's three separate failure modes, each handled differently:
- Your app can't reach Maxlona at all — a network blip, a DNS hiccup, a brief regional outage.
- Maxlona is up but slow, or a piece of it is degraded — a traffic spike, a backend hiccup.
- Something downstream of evaluation has trouble — a webhook endpoint is down, a streaming connection drops.
Each one has a specific answer, not just "we have redundant servers."
How each one is handled
Client integrations can use retries and application-defined fallback values to handle temporary connection failures. Review each SDK's error-handling options when choosing request-path behavior.
Evaluation can use cached flag data to reduce repeated database reads.
Supported streaming clients can be configured to reconnect after a network interruption. Applications should refresh current flag state after reconnecting.
A delivery that fails retries automatically. If it still doesn't land, the delivery history in the dashboard shows exactly what was sent and when, with a manual replay for anything that needs it.
The one decision that's still yours
None of the above matters if your code doesn't have a sensible answer for "what happens if this call fails anyway." That's not a Maxlona setting — it's a design decision you make when you wire a flag into your code: what should the checkout page do if the flag lookup times out? For most features, the safe default is off, so a lookup failure quietly falls back to existing behavior instead of surfacing a broken new one. Decide it deliberately, once, rather than discovering the answer during an actual incident.