Stream: terminology
Topic: statefulness of $closure and horizontal scaling
Michael Lawley (Aug 22 2016 at 03:23):
We've recently been looking at running replicated instances of our terminology server behind a load balancer.
In this mode, $closure is a problematic operation because it is stateful, but the key for that state (the name parameter) is burried inside the body of the POST request. If this were pulled out into the URL itself, e.g., as [base]/$closure/{name} then it would be vastly simpler to ensure that the load balancer was directing the closire table operations to the correct replicated instance (and therefore no need to share this state across instances)
Grahame Grieve (Aug 22 2016 at 07:25):
you wouldn't put all closure operations on the same server?
Peter Jordan (Aug 22 2016 at 08:24):
Less likely to be a problem if Web Servers and DB Servers are on separate physical tiers - the 'classic' architecture for handling client session state in load-balanced distributed apps.
Michael Lawley (Aug 25 2016 at 12:53):
closure for us is not persistent state, only in-memory
directing all $closure operations to a single instance (in the load balancer) would almost work, but fails for $closure inside a batch operation
Michael Lawley (Aug 25 2016 at 12:54):
actually, batch is pretty bad for any kind of front-end that wants to inspect request traffic and do stuff
Grahame Grieve (Aug 25 2016 at 21:14):
yes. I don't see how you can make $closure not persistent
Peter Jordan (Aug 25 2016 at 23:17):
It would be interesting to read @Brian Postlethwaite on the topic of implementing batch operations in a load-balanced environment as his FHIR servers are hosted on Microsoft Azure.
Michael Lawley (Sep 07 2016 at 01:20):
The issue with batch is not so much a load-balance problem as one of request filtering through an API Gateway
Last updated: Apr 12 2022 at 19:14 UTC
