Developer challenges for a scalable messaging solution
It sounds so easy.
"Building an application that sends messages".
How hard can it be?
We send messages all day long,
via many different media...
But once you start building your own messaging solution you will find out there are some tough challenges to overcome.
Based on our own experiences, we have summed up a list of the biggest challenges we came across when developing Ripples, our solution for incident/emergency notification.
A solution with a clear goal in mind.
Inform all your contacts, up to many 1000's, as quickly as possible,
Each with the right message via the preferred media.
To do so you need to solve some technical challenges, as described below.
# Choose the correct message type & provider for your application.
When you develop an application with messaging features
you can choose from many different media ( voice, email, sms etc) via which you want to reach your contacts.
Once you have decided which media type you are going to use
you face yourself with the task to select a provider that will deliver your messages.
Not a task without implications.
As you will have to research and learn the API set of the selected provider.
Choose wrong, and you have to learn another, new API set.
And then we assume, you are 'new school' and have already decided to use the new modern API based service providers
instead of implementing your own infrastructure.
Delivery API supports multiple message types and multiple providers via one and the same API.
So you don't need to choose a media type or a provider upfront
you can simply experiment with multiple and find the best option for your situation.
# Learn different API's for different media
Each provider is unique and has its own set of APIs.
You need to go through each one's documentation and learn how to properly use it
You also have to consider the best practices on how to use each of the provider's API's.
In practice, this means, that when you decide to support multiple media in your application,
You also have to learn different API sets.
Delivery API is providing you the possibility to use multiple providers within a single API,
with just the simple change of a parameter in the same API,
you can send the same message
via multiple types of media and via multiple providers.
# Understand how to integrate the provider in your system
Every use case is different,
And you need to learn how to integrate your data with the selected provider.
Sometimes it's trivial, sometimes it's not,
Depending on where your data is stored and how the provider is managing it.
Delivery API gives you full control on how and where to store your information
And how to use multiple providers and multiple media.
# Set up throttling
Each provider has its own limitations,
And you need to take these into account when writing your software to communicate with each of the providers.
If the limits are reached, the provider may fail to send your request and returns an error,
So throttling and exponential backoff must be taken off in your code.
You may also want to setup throttling because of your own terms with your customers,
or there may be some other infrastructure issues and considerations, based on the media type or provider you chose
that could lead to messages that fail to be delivered
DeliveryAPI already provides the possibility to throttle your messages,
and with only adding one parameter you can specify
how many messages per second or per minute you want to send to the provider, without any code on your side.
# Design for failure
Your code must be resilient to failures.
What happens if one of the providers you are using it is suffering from an outage?
You need to take into account this possibility,
and maybe have a backup provider as a temporary solution,
or you need to put the messages requests in a separate queue to not loose them and send them as soon as the provider is back to be fully operational.
Delivery API lets you easily switch between one provider or another,
so you can easily test your disaster recovery plan
and have your infrastructure ready when a disaster really strikes.
# Set up the infrastructure
This is something that is inevitable.
You need to test your code, setup a proper deployment pipeline and monitor your servers to make sure everything is working properly.
setup a proper deployment pipeline and monitor your servers to make sure everything is working properly.
and monitor your servers to make sure everything is working properly.
Delivery API lets you start using the service for free right now,
without the need to set up another separate infrastructure for you message handling,
and we also make sure to monitor it and quickly fix anything that is not working as expected.
# Architect for scalability
Depending on your use case, you may need to send only a few messages or thousands of messages.
When you design your architecture to scale only for the number of messages you send right now,
you need to change your architecture with new scalability goals in mind when you'll grow and send more messages.
This is not trivial, and you may spend lots of time to change your infrastructure every time you reach new limits.
Delivery API is already designed with scalability in mind,
so you can start for sending messages right now without any monthly fee,
and as soon as your company grows and your needs grow,
you can increase your infrastructure,
with only one click in your console,
without spending any time changing your architecture or changing any of your current code.