Implementing Failover Mechanisms in vConnect: Strategies for Handling API Failures

vConnect
, ,
1

This topic explores the concept of failover mechanisms in vConnect, with a focus on handling API failures in a specific scenario.

The scenario involves creating a service PAN and utilizing two APIs:

  1. IDFY_PAN_API and
  2. KARZA_PAN, in a failover fashion.

Participants in the discussion can share their insights, experiences, and best practices for implementing such failover mechanisms effectively.

Key points of discussion may include designing resilient systems, strategies for detecting API failures, determining the threshold for failure, implementing automatic failover, and considering the implications of failover on performance and user experience.
Participants can also discuss alternative approaches and technologies that can enhance failover capabilities in vConnect.

@Vikas_Dhillon @nimesh.singh @Mayank @naveen.gupta any ideas?

How about making it as a feature request?

2

@naks welcome to the community. Want to share any ideas here.

3

@DebugHorror : Right now, Failover mechanism is available in VahanaHub module but not in vConnect. There is small challenge in vConnect currently as below:

Suppose Service name is VALIDATE_PAN and apis linked with this service are: KARZA_PAN & IDFY_PAN. So you can apply rule that if KARZA_PAN is success then don’t ahead and return the response. In other case, if KARZA_PAN is failed then go to IDFY_PAN. So in this case response object will be changed a little bit for end consumer because JSON Object name have API Name in vConnect response.

So everytime, API Name will be different for consumer. If this complexity of dynamic name can be handled by consumer then Failover can be implemented using below:

One service has two apis and second api is called only if the first apis is failed.

2 Likes
4

Welcome @Vikas_Dhillon to the community and thanks for the valuable post.

I doubt that we can even stop the second api to get executed. There is no way in current implementation to set a BR on API’s response.

Failovers almost always never change response structure. Because one can change vendor at the back end at any time.

5

@DebugHorror : We can stop the second api execution using BRE functionality.

1 Like