He works for a company (holvi.com) that offers business banking services to microentrepreneurs in a couple of countries. Payment accounts (online payments, prepaid business mastercard, etc). Business tools (invoices, online shop, bookkeeping, etc).
Technically it is nothing really special. Django, django rest framework, postgres, celery+redis, angular, native mobile apps. It runs on Amazon.
Django was a good choice. The ecosystem is big: for anything that you want to do, there seems to be a library. Important for them: django is very reliable.
Now: how not to lose your customers’ money.
If you’re just starting up, you might have a reliability of 99.9%. With, say, 100 payments per day and 2 messages per payment, that’s 1 error case per day. You can handle that by hand just fine.
If you grow to 10.000 messages/day and 99.99% reliability, you have 5 cases per day. You now need one or two persons just for handling the error cases. That’s not effective.
Their system is mostly build around messaging. How do you make messages reliable?
The original system records the message in the local database inside a single transaction.
In messaging, it is terribly hard to debug problems if you’re not sure whether a message was send or what the contents were. Storing a copy locally helps a lot.
On commit, the message is send.
If the initial send fails: retry.
The receiving side has to deduplicate, as it might get messages double.
You can also use an inbox/outbox model.
For transport between inbox and outbox, they use kafka, which can send to multiple inboxes.
There are other reliability considerations:
Photo explanation: station signs on the way from Utrecht (NL) to Heidelberg (DE).
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):