With years of experience and observations, I have noticed that almost all system integration implementations follow a common mechanism. With this guide, next time, you can design and test your system integration like a guru.
When the systems are integrated, there are few things to pay attention when designing and testing the integration.
- The communication between the systems
- Retry mechanisms
The communication between the systems
This is the baseline and the bridge between the application for the success of the integrations, sharing of data and validations. We can use different mechanisms to communicate between systems like service call, remote procedure calls and so on. The commonly used communication mechanism is HTTP Rest.
With integration what possibly happens is failing to communicate. Why?
It could be due to the unavailability of subsequent system or failure in authentication and authorization or an internal issue in the application and the list continues. Due to these, it is vital to implement a retry mechanisms.
🤝 If you enjoy reading stories like this and you want to support me, why not consider signing up for a Medium membership?You’ll get access to all stories on Medium!
Designing with retry mechanisms let the system to progress and decide what to do next after a failure in communicating with the subsequent system. Retries let you reduce a lot of manual intervention during failures in communication.
You can decide how many times to retry and how often. For an example, you can retry 03 times without any intervals, or you can retry 03 times with an interval apart. (After 15 mins).
What is good and bad out of the approaches — with or without an interval
- The worse is not having a threshold of retries, for an example if you retry until the request is successful, it is not a good approach as it may end up in a never ending state and system will overload.
- Mainly it depends on your application and business…