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...
So an alternative to Kong inspired by Kong [1]?
I wonder what were the reasons behind building this, can the author(s) weigh in would be interesting to know?
I don't know about this project. But I have been using Kong and eventually have to remove it and run with Nginx directly.
Kong add significan overhead, especially when you use statsd plugin. When under high load, say 10kRPM, Kong has 1-2% error request rate. I endedup removing Kong and use Ingress Nginx directly with some Lua script.
It isn't as efficient and conveniene as Kong but it perfoms better.
Thanks for sharing, it's nice to see that some people are actually seeing performance issues with open source tools, it probably helps the maintainers keep an eye on what's needed to be fixed "next" - well if they read these comments at least!!!
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...