4 ms·

That’s fair, I agree SMS isn’t great for 2FA. I think what’s interesting is that a lot of systems still rely on it anyway (reach, fallback, onboarding), but tr

That’s fair, I agree SMS isn’t great for 2FA. 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?

panny 6mo ago
I sent 100,000 SMS appointment reminders every day for over a decade. I resisted lead times under 1 day for a very long time, until I was forced to roll out lead times as short as one hour. I made extra sure, I got it in writing, that customers would be informed hourly lead time may fail and be unrecoverable. Don't depend on it. Hourly, the shortest lead time was one hour. And you're talking about 45 seconds.
- Bridgexapi 6mo ago
  Yeah that makes sense, especially at that scale. 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?
  - panny 6mo ago
    >they just design around the fact that it’s unreliable 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.
    - Bridgexapi 6mo ago
      [dead]

panny 6mo ago

I sent 100,000 SMS appointment reminders every day for over a decade. I resisted lead times under 1 day for a very long time, until I was forced to roll out lead times as short as one hour. I made extra sure, I got it in writing, that customers would be informed hourly lead time may fail and be unrecoverable. Don't depend on it. Hourly, the shortest lead time was one hour. And you're talking about 45 seconds.

Bridgexapi 6mo ago
Yeah that makes sense, especially at that scale. 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?
- panny 6mo ago
  >they just design around the fact that it’s unreliable 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.
  - Bridgexapi 6mo ago
    [dead]