Skip to main content

smpp-connector — Sync Contract

Status: populated | Last updated: 2026-04-18

1. Consumers of smpp-connector's Outputs

ConsumerInterfaceDependency typeNotes
dlr-processorNATS sms.dlr.inboundAsync eventMust process every DLR event exactly once; uses JetStream durable consumer
routing-engineNATS operator.healthAsync eventUpdates Redis health cache; see routing-engine SYNC_CONTRACT
operator-management-serviceNATS operator.healthAsync eventUpdates operator state records and alerts

2. Dependencies of smpp-connector

DependencyInterfaceFailure mode
operator-management-serviceGET /internal/operators/{id}/smpp-credentialsCannot bind new sessions; existing sessions continue until TCP teardown
NATS JetStreamConsumer smpp.operator.{operatorId}No new messages dispatched; messages queue in NATS until consumer reconnects
RedisTPS sliding-windowIf Redis unavailable: TPS enforcement disabled (fail-open); log warn; alert fires
PostgreSQL smpp schemaINSERT/UPDATE message_correlationsIf DB unavailable: DLR correlation impossible; DLRs published without messageId (best-effort)
MNO SMPP serverTCP + SMPP 3.4Cannot send/receive; exponential backoff reconnection; operator.health UNBOUND published

3. Schema Stability

NATS Event Schemas

EventBreaking change policy
SmsDispatchCommand v1.0smpp-connector is the sole consumer; changes by sms-orchestrator require bumping version and updating consumer logic in the same deployment
DlrInboundEvent v1.0dlr-processor depends on this; breaking changes require version bump and migration window
OperatorHealthEvent v1.0Multiple consumers; breaking changes require broad co-ordination

4. Operator Assignment Contract

Each smpp-connector deployment is assigned a set of operator IDs via the OPERATOR_IDS environment variable (comma-separated UUIDs). It subscribes only to smpp.operator.{operatorId} subjects for its assigned operators. This partitioning is managed by the platform team during deployments.