Speaking as someone who’s written a lot of post-mortems, they’re a really useful exercise, and demanding clients are the only reason they actually happen. If you don’t get any lessons out of your post-mortem process, you’re missing a huge opportunity to improve your services.
In any case, it blocks German Telekom users. There is an ongoing dispute between Cloudflare and Telekom as to who pays for the traffic costs. Telekom is therefore throttling connections to Cloudflare. This is the reason why we can no longer use Cloudflare.
There is no dispute. Telekom is not peering on public exchanges and wants ransom as in expensive private ip-transit contracts from everyone. Their customers are used as a bargain for this. Recently Meta stopped playing that game and Cloudflare never did afaik. Telekom could solve a part of this problem with a few 100k€ and a few weeks time if they would peer at the bigger German exchanges. If every big ISP would act like them the Internet would be dead.
Could this handle more than two databases with this technique or would it generate the mentioned loop when a third database sends the data to multiple databases?
Yes, the implementation distinguishes between a replication client and a user/app client specifically to prevent multiple query invocations. Network latency and CAP tradeoffs still apply of course, but you can absolutely scale well beyond two instances with this.
I've used this one as well, but in terms of functionality, isn't it similar to GitHub Copilot? I find that GitHub Copilot in general works better and seems to understand context a bit better than the ChatGPT + VS code plugin.
