Hi,

Very clear description and I agree with the "avoid mixing network communication with database work" in general. You mentioned "rapid connection pool exhaustion and performance degradation". Yes, it is much easier to size the connection pool when the time spent in the transaction is predictable, and a synchronous call to an external service brings an unpredictable latency. But there may be other solutions, like timeout in the call, or dedicate a connection pool for this. It also depends on the RDBMS used as long transactions may be a problem. Is there an article with more details about this "We’ve learned the hard way that network calls (RPCs) during the Pre and Post-RPC phases are vulnerable" and alternatives solutions considered besides this clean out-of-transaction RPC?

Franck.