[hvindin]

I find it interesting that there seem to be things called out as features which conflict:

1. Recording all requests in a database - feels like only very low value targets could do this. Exposing a database record of requests within the same software stack as your gateway (ie. First line of defense sort of space) feels like its immediately risky. This is why large enterprises tend to rely on their backends to do full white box auditable records keeping but as you move closer to the edge the amount of information stored gets stripped back until you should really only have correlation ID's and time stamps which should be getting shifted off-box in a hurry so they can be ingested internally. 2. Guaranteed immutability of requests which is specifically called out as useful to financial institutions. While I won't deny this is probably a nice thing to have, its also really only valuable in reducing load on your systems of record by removing duplicate requests or refiring them only as needed. As mentioned above, its the core systems of an enterprise like a bank that will be doing all the record keeping. So it will likely also be this core system that is in charge or recognising and rejecting duplicate transactions, otherwise you're throwing a lot of really important decision making about what requests those core systems should see a long way away from those core systems, meaning you are almost definitionally less able to make a sensible decision about if that request should be sent again or not. But then again, you're also that much closer to the client application so might be able to pick a lot up from context that your systems ot record would be oblivious to.

I'm not really sure I can see perfectly clearly where this particular gateway would sit in the ecosystem...