Things to consider when building time-sensitive applications for realtime distribution
Distributing data in realtime has some exceptional challenges which you need to keep in mind when developing an application. In this article I want to have a look at an example I worked on and which things are needed to be considered during the development.
Realtime dissemination: Index value data
The application is in the field of disseminating index value data in realtime to a vendor outside of the system.
Consider the image below as an top-view of the microservice architecture of the system.
The Disseminator component fetches the calculated data from the Calculator and pushes it to the Vendor.
The Calculator is calculating the data in realtime as soon as new stock prices come into the system and offers a WebSocket which can be subscribed to. In the same time as the price is calculated it should be picked up by the Disseminator and send the data through the connection to the Vendor.
In this article I’ll write about the characteristics of the Disseminator and which actions need to be taken for a good design of it. For that consider it being an own service in the microservice architecture and the only one which we can influence.
Deep-dive to the characteristics
Time-sensitive applications have a lot of operational architecture characteristics as they are mission critical for the company: The applications are distributing data in realtime and an outage would cost the company and vendors outside a lot of money. Furthermore the financial world never sleeps, so the application must be reliable!
Check the following table of characteristics which fit to the problem field described above:
| Characteristic | Definition |
|---|---|
| Availability | How long the service needs to be available. |
| Continuity | Capability to recover from disasters. |
| Performance | How good the service acts on full loads. |
| Recoverability | Business continuity after disasters or data loss. |
| Reliability/safety | Fail-safe service design. |
| Robustness | Handling of data and network connection loss. |
| Scalability | Performing on increased user numbers. |
All of these characteristics need to be fulfilled by the application to assure that the business model from the company is aimed.
Check the problem fields
Well, you can not tell the diagram from above an architecture diagram, but at least it helps us to understand the problems which can appear within the application.
Below you can see the diagram from above with number labels. These numbers are the places where the following problems (or some of them are also ‘risks’) can appear:
- Network connection to the
Vendor - Network connection to the
Calculator - Data loss
- Protocol false implemented
- Timezone switching
- Performance
As you see beside of the connection all risks lay inside the service itself. So we need a good design of the application to fullfil characteristics from above and assure that our goal of a good application is reached!
We will go step by step through the points and check why you need to take attention to them and how we can weaken them.
1. Network connection to the outside
One critical point is the network connection to the outside. As soon as your data goes outside, you cannot influence anything anymore.
A network is never reliable, so it can lower the robustness, continuity and reliability of your application.
Redundance can help you with that. You can improve this points by implementing active/passive connections, do different deployments in different geographical places or create a (also redundant) direct connection to the vendor outside. All this depends on the budget as it can be a not so cheap solution!
2. Network connection to the Calculator
Everything from the first point can also be applied on the network connection to the Calculator as it is the same problem field.
But if this application is running inside the same cluster you can think of removing some overhead like e.g. running the applications side by side in the same node/cluster and network. This would also improve the performance.
3. Data loss
The risk of data loss is a huge one! You can differ between two data loss scenarios:
- Your application is dead and doesn’t distribute the data anymore.
- The network connection is dead and the data cannot be distributed.
By good design at this point you can improve the recoverability, reliability and robustness of your application.
Let’s break down what you can do:
First you can store all data which you want to send in a (redundant) cache outside of your application like a Redis server. Second check if the protocol which you are implementing against allows to resend (ordered) data after a connection outage. This can assure that data just arrives late after outages! Furthermore again a passive/active architecture can help: When the active application or connection fails, you can activate the passive one and go on with that application.
4. Protocol false implemented
When the third-party against you are running has problems to understand your messages you have maybe implemented the protocol in a false way. So, read the specification of the third-party and implement it correctly to prevent these issues. You can increase this reliability by testing input/output values.
5. Timezones and DST/Standard time bad handled
When you are disseminating data you need always to ask these questions:
- At which timezone lives the receiver? Does the receiver follow timing rules?
- In which timezone the data needs to be?
- At which timezone is my application running?
Depending on this you need to design your application to handle different timezones or DST/Standard time switches. Also maybe your data needs to be send in a specific timezone and format (like UNIX timestamp or ISO-8601).
6. Performance
The performance of your application to handle incoming events and send messages to the third-party in a fast way affects your performance.
You can design the application multi-threaded, event-driven and replicate it in your cluster to increase the performance and scalability: When you want to send hundreds of different messages in parallel this will help you!
On availability and continuity
Some points have already been mentioned regarding the redundancy of the application, which also affects the availability and continuity characteristics of the service. I just want to point out that beside of a good design and implementation a replicated instance can help you in a lot of ways. You introduce other problems with this approach, but overall in long-term it will let you sleep well when you know that in any cases your application is available!
Conclusion
You can see that the analysis figured out different points of risks and design considerations which should be payed attention during the design and development of the application. Furthermore you do have actions to do on the infrastructure to allow your application to act as wished.
The analysis points this out. You can show this (maybe with a better diagram ;) ) your stakeholders to convince them that you need the time, money and resources to apply all these things to your application.