The actual logic that is involved with processing a single SMS is not exactly trivial, but here is an overview of how the messages and delivery reports travel through our systems.
Messages being sent to mobile devices aka MT SMS. Most often these are notifications from systems or services to a person, but other traffic also fits this category.
The API receives the request and performs a bunch of validation, assuming that the data adheres to our schemas it is put passed to the queue and processing systems.
The schema does many checks on the data, but crucially it does not check if a SMS would be deliverable, simply because such a check would take to long to be reasonable within the time of a API request. Instead, once the API has verified that the SMS in the request could be sent, it is passed to the next step.
The heart of the system. Here the SMS is saved to our databases and we route the SMS towards operators based on the recipient MSISDN and sometimes specific customers preferences.
This is also the step where we have the time to perform more expensive checks, such as running each SMS through out malicious use filters, and rejecting the SMS if there is a match.
Then the SMS is actually forwarded towards by many specific connections. Some use SMPP and others a custom HTTP connection. Some connections are able to absorb more traffic than others, but in the end most operators impose a limit on how many SMSes can be submitted in a given time interval.
Once the SMS has been accepted by the operator or gateway we routed to, we begin to receive status reports. These we then pass to the processing systems back again where the destination of the delivery report (if any) is looked up and the report passed to the webhook system.
Sending a delivery report is actually just a content encoding step and a HTTP request, quite simple actually. The complexity arises from imposing a throttle so most reports would arrive safely instead of sending off so many requests that the server becomes unable to respond.
Messages being sent from devices aka MO SMS. This is most often in the form of replies to a previous MTSMS from a service as above.
When an MOSMS arrives to our systems, via one of our many connections. The system backing the connections perform some very basic validation and passes it forward to processing.
We then use either the recipient number to determine message destination.
In case the whole number is owned by a single customer. Or we extract the keyword (the first word in the message text itself) and use the recipient number in combination with keyword, in case it is a keyword on a shared number.
Once the message destination is determinted, we pass the message over to delivery.
Final message delivery happens either to the customers webhook or via the a connected SMPP connection, depending on configuration.