How to build 99.999% uptime payment systems | Hacker News Reader

How to build 99.999% uptime payment systems

news.alvaroduran.com

18 pointsohduran12 comments

I was very much interested to understand anything close to helpful information, but all I hear is “Everything is in that book”.

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.

Development is in-progress and plan for first platform release likes somewhere in Q1 2025

1. Product Documentation - (https://openpayments.tech)

2. Developer Portal - (https://portal.openpayments.tech)

codetiger,

Kudos on your efforts for building an open RTP solution as many entities are now positioning to own their payments engine cutting out the middlemen, even the whole of some nation states. I have decades of experience in extreme uptime solutions including Fintech having founded, architected, coded, certified, and managed multiple PCI Level 1 compliant payment entities in entirety since 1997. Per your ask feel free to email me to engage in discussion.

Stay Healthy!

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?

Maybe it’s me but I have a hard time reading this article, it is so vague. It hints at concepts and ideas, yet nothing is really explained.

It's a sales pitch (for his book) masquerading as technical article

Not just you, I don't have a clue what this article was trying to teach me. I was expecting an interesting read.

I saw one paragraph on transaction isolation levels hidden in the word salad

> Stripe gets 99.999% uptime on top of a MongoDB-like database

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.

[1]: https://stripe.com/blog/how-stripes-document-databases-suppo...

Stripe runs a ton of Mongo replication clusters and uses home-grown proxy services on top of Mongo that manage and control where data lives, so the services don't have to think about that side of things. I'm not sure what changes have been made to Mongo itself but for the most part it's standard Mongo 4.

If you take open source MongoDB and add 10 lines of custom proprietary code, is it still MongoDB? What about a hundred, or a thousand, or a million? What if you change the interface? Ultimately you can give the modified service any name you want, and whether it is "actually MongoDB" or not is a subjective judgement.

The explanations given for uptime are topics about performance & correctness in database.

Is it just me, or does that have nothing to do with uptime?

Reply on news.ycombinator.com