Transactional vs Marketing Traffic on the Same Gateway

The shared-route problem

When traffic is small, it's tempting to send everything down the same vendor route. One integration, one set of credentials, one bill.

This works until the first marketing burst collides with peak OTP traffic. Then:

• Transactional latency spikes from sub-second to 20–60 seconds
• Some OTPs arrive after the TOTP window has closed
• Conversion on the login flow drops 5–15%
• The marketing team gets blamed; nobody can prove what actually happened

The root cause is almost always shared routing across traffic classes that have very different characteristics.

Why the two classes don't mix

Transactional traffic (OTPs, password resets, alerts):

• Latency-sensitive (must arrive in under 10 seconds)
• Bursty (login spikes, hour-of-day peaks)
• Low absolute volume per user but high reputation impact per failure
• Regulator and operator-friendly content

Marketing traffic (promotions, win-backs, announcements):

• Latency-tolerant (delivery within minutes is fine)
• Predictable (campaigns are scheduled)
• High absolute volume
• Subject to opt-in scrutiny, content filtering, and time-of-day restrictions

Carriers and aggregators apply throttling at the route level. A 200,000-message marketing burst doesn't just slow itself down — it slows everything sharing that route.

How to separate properly

There are three layers to get right.

1. Separate sender IDs

Use distinct sender IDs (or short codes) for transactional vs marketing. Operators apply different filtering rules per sender ID. Sharing a sender ID across both classes means either:

• The transactional sender gets flagged because of marketing content, or
• The marketing sender gets cleaner treatment because of transactional reputation, then loses it after the first content review

In the US under 10DLC, the registration also differs — declared use case affects throughput tier and filtering posture.

2. Separate routes (and ideally vendors)

Even with the same vendor, request separate route IDs for the two traffic classes. Better, route them through different vendors entirely. This gives you:

• Independent throughput allocations
• Independent failure domains
• Independent throttling behaviour
• Independent contracts and SLAs

Most managed gateways will let you express this as a routing rule: traffic class → route → fallback route.

3. Separate monitoring thresholds

Once routes are separated, monitor them differently:

• Transactional: alert on p95 latency over 10s, conversion drop over 3% in 5 minutes
• Marketing: alert on DLR rate under 95%, vendor throttling errors, spam-flag rates

Triggering a 3am page for a marketing campaign that delivered slowly is noise. Triggering one for a 4-second OTP latency increase isn't.

The operational model

In production, the routing rule looks something like this:

if traffic_class == "otp":
    primary = vendor_a / route_otp_priority
    fallback = vendor_b / route_otp_secondary
elif traffic_class == "transactional":
    primary = vendor_a / route_txn
    fallback = vendor_b / route_txn
elif traffic_class == "marketing":
    primary = vendor_c / route_marketing_bulk
    fallback = vendor_a / route_marketing

The key constraints:

• Marketing never falls back onto OTP routes
• OTP fallback is a vendor with a warm route, not a cold standby
• Cost optimisation only applies to marketing traffic; OTP is optimised for latency

Where shared infrastructure is OK

The application layer can absolutely share infrastructure across classes — same API, same observability stack, same support team. The separation needs to happen at:

• Sender ID
• Vendor route
• Throughput allocation
• Alerting thresholds

Everything else can be unified.

Common mistakes we see

When we onboard a customer with a degraded delivery profile, the diagnostic almost always finds one of these:

1. A single sender ID being used for both OTP and marketing because "it was easier"
2. Marketing campaigns scheduled during peak OTP hours
3. A shared route that's hitting throttling ceilings during marketing bursts
4. No alerting differentiation, so the on-call team is desensitised to marketing-related noise

All four are fixable in days, not weeks.

---

If your delivery numbers feel inconsistent and you suspect traffic-class collision is the cause, book a 30-minute messaging review. We'll look at your routing setup and tell you what to fix first.