From a purely technical perspective, you would just distribute requests inversely proportional to response time. Probably under low load, one provider would get all the requests, and only in an outage or overload scenario would the other provider take the rest.
Where did that constraint come from? Did I miss it in the article? Their initial approach, after all, had all of their load going to a single provider.
Gotta keep the service provider happy to ensure they still go along with the program.
The problem is you pick a SMS aggregator. They all tell you they have global coverage, and direct routes. They all tell you that their routing algorithm is the best of all the aggregators. And they're all full of BS.
If they weren't full of BS, I wouldn't have had a nice job managing verification code sending for a big messaging company though, so I guess it worked out for me. :P If SMS worked in general, the messaging company probably wouldn't have existed.
“Developed and researched a novel algorithm to reliably send messages under intense load”
Or
“Tried 5 off the shelf solutions, picked 1 that seemed okay, and moved on with my life”
That’s why we keep reinventing the wheel. Also it’s fun and we all think we’re the smartest.
Neigher. Focus on achieved business outcomes instead.
"Scaled GOV.UK Notify to 15 messages per second, ensuring reliable and timely delivery of 2FA codes and flood emergency warnings."
"Developed and researched" tells me you did something interesting but I can't tell if it was resume padding or real work. If you can't articulate why, that's a red flag. A good hiring manager should be able to detect resume padding and avoid hiring people that waste company resources on pet projects.