I think what’s interesting is that a lot of systems still rely on it anyway (reach, fallback, onboarding), but treat it like it’s deterministic.
In practice, I’ve seen more issues from unpredictability than just security — timing, routing behavior, stuff you can’t really see.
So even if teams accept the trade-offs, they still don’t really understand how delivery behaves.
Have you seen similar issues in systems that still use SMS as fallback?
Hourly, the shortest lead time was one hour. And you're talking about 45 seconds.
What you’re describing is kind of what I keep running into too — people don’t really try to understand delivery, they just design around the fact that it’s unreliable.
Longer lead times, retries, fallback channels, etc.
Which works, but it also means the actual behavior stays a black box.
Did you ever notice differences between providers or routes, or was it basically opaque the whole time?
Everything is unreliable. Always design for unreliable. That's my major gripe with most docs and tutorials from any of these services. They only describe what happens during success. They never go into detail on what happens when things go wrong. Your only option is to wait for it to blow up and learn from experience. In the meantime, assume it is going to blow up, try to catch it and log as much of the blowup as possible. Never assume it will work. Assume it won't work and be happy when it does.
This is why you should lean toward something like an authenticator. You can control the whole experience. Rely on unreliable services as little as you can.