We improved the DLR processing time for high-priority messages viz. OTP from 2hrs to 5 secs, with more than 99% efficiency.
An SMS delayed is an opportunity denied
An OTP is: A one-time password [could be 4-8 digits] that is generated randomly and is sent to the user’s registered mobile number in order to complete a financial transaction, or in some cases login process. Validity of OTP ranges from 30 to 300 seconds.
High-priority/OTP channel: The message is delivered to the user’s handset in <=5 secs, in order to complete an activity/transaction initiated by the user.
Trans (transaction) channel: This channel is used to send messages to report a transaction / activity that the user has already completed, for e.g. a notification informing them of an order they just placed with you. It’s important, it’s urgent too, but it’s sent after your transaction is complete.
Promo (promotion) channel: This is for general marketing-related messages sent to a target group.
Let’s talk about DLRs!
If we tell you DLR stands for delivery reports, the whole thing becomes self-explanatory. Telecom operator notifies the status of the SMS sent to the user’s handset in the form of DLR.
DLRs are important because…
A business enterprise sending messages to its end users would need to know which messages were delivered and which weren’t – think of those double ticks on WhatsApp messages, where single tick means ‘sent’ and double ticks mean ‘delivered’. Similarly, the enterprise also needs to know whether the message was delivered and for this they are dependent on the DLRs. As soon as the enterprise is notified that the message was not delivered within the stipulated time, they can send the same message through other channels in order to avoid the loss of business.
For instance in the airline business, crew members are supposed to be informed about their flight details a certain number of hours before their scheduled flight. If the DLR says ‘undelivered’, the system uses voice call option. However, if the DLR itself is delayed, the voice call will be also be delayed, thereby holding up the entire process including the ground-level execution, resulting into chaos and loss of business.
Story of processing DLRs: Then & Now
Historically, the processing time for 95% of OTP DLRs used to be as high as up to 2 hours. But now, we have widely improved the architectures such that we are able to process more than 99% of OTP DLRs in <=5 seconds. That’s kudos for digital ecosystems! Smartech sends more than 3+ billion SMSes per month from our platform.
So how did Smartech do this?
We use Redis as our backbone for DLR processing and reporting apart from other in-memory databases, for our various Mobility Solutions.
Earlier, we were using only one Redis instance – it was single-threaded. We realised we needed to do better than that to service a huge number of simultaneous connections to increase throughput. So, we got multiple Redis instances and also used Redis pipelining which can execute multiple commands on a single network call, thereby reducing number of connections and increasing throughput. Talk about multitasking!
More change was due: Earlier, we were using language-dependent objects as data interchange format and it was eating up huge chunks of time in object serializing and deserializing. Also, we were restricted to the use of a specific language at the ‘receiving’ end. We picked another alternative – JSON, which is a standardized lightweight data interchange format that is also language inter-operable. Our end-to-end data transfer rate went up.
Furthermore, the applications and the DLR Processes connect to Redis using a dedicated network card of 1Gbps instead of shared network card. This helped increase our bandwidth and throughput. Using sequential operation processing rather than parallel operation processing for DLRs further improved the performance. With consistent monitoring, fine-tuning, and after several iterations, we achieved the milestone of [High Priority] OTP DLRs being processed and made available within 5 seconds.
Our awesome SMS DLR Manager dons a simplified look here:
