I was very much interested to understand anything close to helpful information, but all I hear is “Everything is in that book”.<p>Am working on building a high performance payment processing engine based on iso20022 standards and looking for such information. Would like to hear some feedback on my design documents and overall.<p>Development is in-progress and plan for first platform release likes somewhere in Q1 2025<p>1. Product Documentation - (<a href="https://openpayments.tech" rel="nofollow">https://openpayments.tech</a>)<p>2. Developer Portal - (<a href="https://portal.openpayments.tech" rel="nofollow">https://portal.openpayments.tech</a>)
A lot of advice on how to achieve "high uptime" focuses on the technical bits. The technical bits are important, but the bigger risk is the people component. I've been in this game for decades and I've seen time and time again that all it takes is one bad hire who likes to roll out changes carelessly, bypassing any change managememt board, to break your uptime SLA for the entire year. You can fire or discipline that developer after the fact but at that point it is too late. See for example: this year's Crowdstrike outage.
Not technical/concrete (examples are missing!) enough for me to really understand what techniques the author is getting at. How would the author achieve all these exclusion mechanisms in a distributed system instead of letting the database engine handle that?
> Stripe gets 99.999% uptime on top of a MongoDB-like database<p>Isn’t it actually MongoDB? They describe it as an “extension” [1] but it sounds like they added cluster management without changing the database itself.<p>[1]: <a href="https://stripe.com/blog/how-stripes-document-databases-supported-99.999-uptime-with-zero-downtime-data-migrations" rel="nofollow">https://stripe.com/blog/how-stripes-document-databases-suppo...</a>
The explanations given for uptime are topics about performance & correctness in database.<p>Is it just me, or does that have nothing to do with uptime?