biya:~$ ls -lt notes/engineering/
Engineering
How the payments work, and what we learned when they did not. Mostly incidents, with the reasoning that missed them.
Payments in a chat window: the four constraints that shape everything we build
No app to download means no client state, no session, and no screen you control. Here is what that actually costs, and the three-outcome rule that took us longest to learn.
6 min
Our default value was not a valid value
A field defaulted to null. The list of allowed values did not include null. Every new merchant signup failed at the last step.
Fadoski3 min
The request never arrived, and the error message blamed the database
Staff could not submit a payment request. The error pointed at MongoDB. The request had never reached MongoDB, or the backend, or the network.
Fadoski6 min
Our failover worked perfectly. That is how we missed a 100% failure rate.
A provider rejected every data purchase we sent it for weeks. Every customer was served. Nothing alerted. The fix was one log line.
Fadoski6 min
One service talks to every provider. Our products get one kind of answer.
Our products used to talk to every airtime, data, electricity and TV provider themselves, and each provider has its own login, its own plan names, its own status codes and its own idea of when to tell you the outcome. Now one service does all of that, and the products send it a request in their own words and get back a uniform answer.
Fadoski16 min