DEV Community

IngramCole6479
IngramCole6479

Posted on

Go Transactional SMS Alerts: Compare Provider Delivery in US and Europe (Cost Notes)

#go #sms #ecommerce #reliability

Short answer: for transactional SMS alerts, compare each provider's delivery evidence in the US and Europe, then choose the route that makes idempotency and regional compliance explicit; a low per-message quote is secondary when a missing receipt can hold an order report hostage.

I am designing an e-commerce service that sends a generated report as an email attachment and a short SMS alert when the report is ready. The alert is not the report itself. It is a time-sensitive pointer, and that distinction changes the provider comparison: the system must prove which event happened, avoid duplicate texts, and recover when a carrier declines a message. Integration effort is the primary axis; pricing and delivery are inputs to that decision, not the decision by themselves.

How do US and Europe teams audit transactional SMS delivery?

The first invariant is exactly-once intent, even though SMS networks provide at-least-once behavior. A report job gets one stable notification key such as order-84721:report-ready:v3. Every retry, worker restart, and provider failover uses that key. The ledger records the intent before a network call, then records the provider response and each asynchronous delivery receipt. This creates an audit trail that can be reconciled with the order database rather than trusting a dashboard counter.

The second invariant is that an SMS never carries authority to download the attachment. The message points to a short-lived, authenticated URL; the email contains the attachment and the same report identifier. A recipient can receive two alerts without receiving two reports, and a delayed receipt cannot cause a second fulfillment action. That boundary is useful for fraud review and for data-minimization requirements in both the United States and Europe.

The third invariant is regional policy. Store the destination country, sender type, consent record, and template version alongside the notification. A US long code, a European alphanumeric sender, and a regulated one-time-password flow have different registration and throughput rules. NIST's digital identity guidance treats SMS as a restricted authenticator for some assurance levels, so an alert should not quietly become the sole authentication factor.

Here is the compact decision table I use before looking at a rate card:

Option Integration effort Delivery evidence Main trade-off
One provider, one regional policy Low Depends on receipt webhooks and retention A policy or carrier gap affects every destination
Two providers behind one adapter Medium to high Strong if events share one internal schema More credentials, reconciliation paths, and test cases
Direct carrier or aggregator contracts High Contract-specific reports Operational and compliance work moves to your team

The catch is important: a single route is not suitable when the business needs independent carrier paths, strict data residency, or a contractual delivery SLA that the route cannot document. In that case, keep the adapter and ledger, then add a second route; do not scatter provider calls through checkout code.

The provider comparison is a governance exercise

Compare a complete notification attempt, not a nominal SMS price. For each destination cohort, measure accepted, delivered, expired, rejected, and unknown outcomes; record the time from queue admission to each transition. Include sender registration, number leasing, carrier surcharges, URL shortening, and the engineering time needed to validate opt-out behavior. Public prices change, and I am not sure any static table remains accurate for every country, so a dated test matrix is more honest than a universal winner.

The familiar names illustrate why the matrix matters. Twilio exposes messaging APIs and status callbacks; Amazon SNS integrates naturally with AWS credentials and eventing; Telnyx emphasizes programmable messaging and number management. Sinch and MessageBird (now often presented under the Bird name) also expose messaging products, but their country coverage, sender registration workflow, and receipt semantics must be checked for the exact destinations. Those are objective integration differences, not a ranking. A route that is simple for an AWS-native team may add identity and observability work to a Go service outside that ecosystem.

For every candidate, run the same synthetic cases: a US mobile that accepts immediately, a European number requiring sender registration, an invalid number, a subscriber who replies STOP, and a provider timeout after acceptance. Keep payloads non-sensitive. The result should be a row of evidence with a correlation ID, not a screenshot. Delivery percentage alone hides the costly state where a provider accepted a message but never emitted a receipt.

I once treated a 202 Accepted response as completion and released a report banner. A worker restart then replayed the job, and two alerts went out. The fix was a unique notification key plus an outbox record; the number that mattered was duplicate_intent_count = 0, not the provider's cheapest displayed unit rate. Small detail. Big difference.

Receipts are evidence.

A critical path that survives retries

The application writes the report and notification intent in one database transaction. A dispatcher claims the outbox row with a lease, sends through a narrow interface, and stores the provider message ID. Receipt handlers only append events; a separate projector computes the current state. This keeps a late delivered event from rewriting the original intent and makes replay deterministic.

package notify

import (
    "context"
    "fmt"
)

type SMSRequest struct {
    Key     string
    To      string
    Body    string
    Country string
}

type Sender interface {
    Send(ctx context.Context, req SMSRequest) (string, error)
}

type Ledger interface {
    Claim(ctx context.Context, key string) (bool, error)
    RecordAccepted(ctx context.Context, key, providerID string) error
    RecordFailed(ctx context.Context, key, reason string) error
}

func Dispatch(ctx context.Context, sender Sender, ledger Ledger, req SMSRequest) error {
    claimed, err := ledger.Claim(ctx, req.Key)
    if err != nil {
        return fmt.Errorf("claim %s: %w", req.Key, err)
    }
    if !claimed {
        return nil // Another worker owns this intent, or it was already sent.
    }

    providerID, err := sender.Send(ctx, req)
    if err != nil {
        return ledger.RecordFailed(ctx, req.Key, err.Error())
    }
    return ledger.RecordAccepted(ctx, req.Key, providerID)
}
Enter fullscreen mode Exit fullscreen mode

The adapter must normalize provider-specific states into a small internal vocabulary: accepted, delivered, failed, expired, and unknown. Preserve the raw event, timestamp, and signature result as well. A receipt endpoint should authenticate callbacks, reject replays, and return quickly; reconciliation can later query provider records where that capability exists. Never infer delivery from an HTTP success alone.

That last sentence deserves operational detail. Suppose the dispatcher times out at 2.5 seconds, while the provider accepted the message at 2.4 seconds and emits its receipt 20 seconds later. Retrying immediately can create a duplicate. If the same request reaches a second route, the ledger must retain both provider IDs, mark one intent as superseded only after a policy decision, and let the projector explain the final state to support. A nightly reconciliation job should sample accepted-without-receipt rows, compare them with provider records, and leave an auditable reason for every transition. The exact timeout and sampling interval depend on carrier behavior; your mileage may vary, but the state machine should not.

For the email attachment, keep the same report key but use a separate channel record. If email succeeds and SMS fails, the user can still retrieve the report; if both fail, the job remains visible to an operator. That is a better failure boundary than coupling report generation to a synchronous text request.

Cost belongs after the failure boundaries

I reject a direct provider call from the report worker. It looks efficient in a prototype, yet it mixes rendering, network timeout policy, consent checks, and financial-grade audit data in one retry loop. It also makes a provider swap a code change in the job path, which is exactly the integration cost this decision is meant to control.

That option is valid for a low-risk internal notification with no customer data, no opt-out obligation, and a human who can resend manually. An e-commerce report alert has none of those properties. The adapter and outbox add a little schema and queue work, but they let the team test delivery policy without regenerating reports.

Cost still belongs in the review. Record the full monthly invoice, message segments, rented numbers, and engineering hours; do not promise a percentage saving from a rate card. Stick with the simpler route when volume is modest and its regional policy is documented. Move to multiple routes when an outage domain, residency rule, or audit requirement outweighs the extra integration effort.

References

Top comments (0)