123eworld Knowledge Hub → Transactional SMS → Page 160
Transactional SMS API Provider Routing: Failover, Health Scoring, Cost, Capacity and Delivery Optimization
How to design provider routing for transactional SMS using health signals, capacity, destination rules, cost controls, failover and observable routing decisions.
Why routing is a platform capability
An SMS platform may use several providers because destination coverage, capacity, pricing, sender support and reliability vary. Provider routing should therefore be treated as a policy and decision system rather than a hard-coded if-else statement.
Eligibility first
Before scoring providers, eliminate routes that cannot legally or technically handle the message. Check destination, sender, message type, tenant configuration and provider capability. An ineligible provider should never win because it happens to be cheap.
Health signals
Use provider error rate, latency, throttling and delivery-report freshness as health signals. Health should be measured per route or destination class where possible because a provider can be healthy in one region and degraded in another.
Capacity
Routing must consider available capacity. Sending traffic to the cheapest provider when its queue is saturated can increase customer delay. Capacity signals should influence both route selection and worker concurrency.
Cost
Cost can be one input, but it should not override service objectives or route eligibility. A cheaper route with poor delivery performance may cost more through retries and customer dissatisfaction.
Failover
Failover should be controlled. A single timeout should not necessarily move traffic immediately. Use thresholds, circuit breakers and cooldown periods to avoid route flapping.
Sticky routing
Some messages benefit from consistent provider selection because status correlation or sender registration may depend on a particular route. If sticky routing is used, define when the platform is allowed to break stickiness during a serious outage.
Routing decisions
Record the provider route selected, configuration revision and major decision inputs. Support should be able to answer why a message used Provider A rather than Provider B.
Tenant controls
Enterprise customers may have approved provider routes or contractual restrictions. Tenant routing policy should be applied before global optimization so the platform does not violate customer configuration.
Testing
Simulate provider slowdown, rejection, capacity exhaustion and regional failure. Verify that routing changes gradually, preserves message identity and does not create duplicate provider submissions.
Observability
Track traffic share, latency, error rate, delivery performance and failover volume by provider and route. Routing dashboards should show both the decision and the outcome.
Production checklist
Define eligibility, health, capacity, cost weighting, failover thresholds, stickiness, tenant policy, decision logging and route-level metrics.
Developer takeaway
Good routing is observable policy. The system should choose a provider for a reason that can be measured, explained and changed safely.
Implementation architecture
Implement routing as a deterministic policy decision. First evaluate eligibility, then apply tenant restrictions, health, capacity and service-policy weights. Store the selected provider, route configuration revision and decision metadata with the provider attempt. A routing decision should be reproducible enough for support to understand why one provider was selected without exposing proprietary scoring details.
Operational reference
Provider routing should avoid rapid oscillation. If health scores change every few seconds and the router moves traffic immediately, providers can repeatedly gain and lose traffic. Use smoothing, cooldowns and minimum traffic windows where appropriate.
Operational reference
Route health should be destination-aware. A provider can have excellent performance for one country and poor performance for another. Aggregating everything into one score can hide these route-specific failures.
Operational reference
Cost optimization should be measured against total transaction outcome. A cheaper provider that causes more retries or support cases may not be cheaper at the platform level.
Production checklist
Production check: verify provider eligibility, route health, capacity changes, failover, tenant restrictions and routing-decision traceability.
Additional implementation guidance
Provider routing should separate hard eligibility from optimization. Eligibility answers whether a provider can handle the message; optimization decides which eligible route is preferable. Mixing these concerns creates confusing decisions and difficult debugging.
Additional implementation guidance
Health scoring should avoid reacting to a single failed message. Individual failures can occur for destination-specific reasons. Use rolling windows and error categories so the router responds to meaningful dependency degradation rather than noise.
Additional implementation guidance
Capacity should include both provider limits and platform-side connection capacity. A provider may have available contractual throughput while the platform has exhausted its own connections or worker slots.
Additional implementation guidance
Failover can increase duplicate risk when the original provider outcome is uncertain. Route switching should therefore use the same logical message and attempt records described in the idempotency architecture.
Additional implementation guidance
Tenant-specific routing policies should be applied before generic cost optimization. If a customer requires a particular route, the global optimizer must not silently override that requirement.
Additional implementation guidance
Routing decisions should be observable but not necessarily expose proprietary scoring formulas. A support record can say that a provider was selected because it was eligible, healthy and within capacity without exposing every internal weight.
Additional implementation guidance
Provider performance should be reviewed over time. A route that performs well today can degrade later, so routing policy should be data-driven and regularly recalibrated.
Reference architecture note
A provider router should also understand configuration freshness. If an administrator changes provider eligibility or a route is suspended, workers using stale cached configuration can continue making incorrect decisions. Use versioned routing configuration and observable invalidation. During an incident, operators should be able to identify which configuration revision selected a provider. This evidence is particularly useful when two messages sent seconds apart appear to have taken different routes because a configuration change occurred between them.
Advanced production guidance
Routing policy should have a safe default when health information is unavailable. The system should not assume a provider is healthy simply because its monitoring data is missing.
Advanced production guidance
Provider onboarding should include route tests for sender, destination, authentication, throughput and receipt processing before production traffic is enabled.
Advanced production guidance
Cost data should be versioned because provider prices change. A routing decision should be explainable against the price configuration active at that time.
Advanced production guidance
Route changes should be introduced gradually. A new provider can receive controlled traffic before becoming eligible for the full workload.
Engineering reference
Provider routing should support a controlled maintenance state. An operator should be able to remove a provider from new traffic while allowing existing attempts to finish according to a documented policy.
Engineering reference
Route health should be based on meaningful signals rather than a single global uptime check. Provider authentication can succeed while a specific destination route is failing.
Engineering reference
Routing configuration should have rollback capability. If a new weighting or provider mapping causes unexpected behaviour, operations should be able to restore the previous revision quickly.
Final engineering guidance
Routing policy should be reviewed with delivery and support teams because a technically optimal route may have customer-visible implications such as sender consistency or delayed receipts.
Final engineering guidance
Keep provider adapters separate from routing policy. The router should select a route, while the adapter handles provider-specific authentication, payload format and response parsing.
Final acceptance test
The final acceptance test should disable a provider route and verify that eligible traffic moves according to policy while ineligible traffic is rejected safely. Confirm that every routing decision remains traceable.
Additional reference
Provider routing should support explicit route suspension for planned maintenance. This is safer than waiting for error rates to rise and allows operators to move traffic gradually.
Additional reference
Keep routing policy changes reversible and test them with synthetic traffic. A small controlled route change can reveal configuration mistakes before they affect high-volume production traffic.
Closing reference
Provider selection should be reviewed after major delivery-performance changes. The router is a policy engine, so its inputs should be measured and recalibrated rather than left unchanged for years. Keep the decision model understandable enough that engineering and operations can validate it during incidents.
Final knowledge-base note
Routing documentation should explain the difference between eligibility, health and optimization. This gives developers and operators a mental model for why a provider may be excluded even when it appears inexpensive or technically reachable.
Continue through the 123eworld Knowledge Hub
Explore the complete 123eworld Knowledge Hub for practical SMS API, transactional messaging, queue, security and developer architecture guides.
Visit 123eworld.com for messaging and digital communication services.