0

I am trying to make my Service Fabric service, which makes a SOAP call to an external service, such that if deployed over 2 or more clusters, it can still work, in that if one service has made the connection to the external service, then the service in the other cluster doesn't try to make the connection, and vice versa.

I can't think of a better way to design this without storing the state in a database, which introduces a host of issues such as locking and race conditions, etc. What are some designs that can fit in this scenario. Any suggestions would be highly appreciated.

user420
  • 131
  • 2
  • 12
  • Why would one node in the cluster fail and the another be successful in calling that external service? Is a retry policy not good enough? – Peter Bons Jul 18 '18 at 11:21
  • @user420 Can you please explain in more details what is the purpose of this service? What is expected from the service that didn't make a call? Does this service will work and process user requests? – Oleg Karasik Jul 18 '18 at 12:03
  • @PeterBons It's a connection made to an endpoint over SOAP and if another service tries to make the connection over the same endpoint, it will kill it. – user420 Jul 18 '18 at 13:00
  • @OlegKarasik the purpose is to send important messages across the external source, and must be processed singly over a connection at a time. – user420 Jul 18 '18 at 13:03
  • @user420 one more question, by "2 or more" cluster do you mean 2 or more Service Fabric cluster or 2 or more physical cluster united into single Service Fabric cluster? – Oleg Karasik Jul 18 '18 at 13:36
  • @OlegKarasik I mean 2 or more Service Fabric clusters across two different physical regions – user420 Jul 18 '18 at 14:06
  • @user420 the I think you should check ways suggested by Diego. Thanks for the clarification. – Oleg Karasik Jul 19 '18 at 11:05

1 Answers1

2

There is no way to do that out of the box on Service Fabric.

You have to find an approach to orchestrate these calls between clusters\services, you could:

  • Create a service in one of the clusters to delegate the calls to other services, and store the info about connections on a single service.
  • put a message in a queue and each service get one message to open a connection(this can be one of the approaches used above)
  • Store in a shared cache(redis) every active call, before you attempt to make the call you check if the connection is already active somewhere, when the connection close you remove from the cache for other services be able to open the connection, also enable expiration to close these connections in case of service failure.
  • Store the state in a database as you suggested
Diego Mendes
  • 10,631
  • 2
  • 32
  • 36