An oral history of Bank Python

𝘉𝘢𝘤𝘬 𝘵𝘰 𝘉𝘢𝘴𝘪𝘤𝘴: go read Cal Paterson’s “An oral history of Bank Python”. It describes a class of software systems that run inside large investment banks, and it is a instructive case study on software architecture. You will probable start reading and thinking “wow, this does not seem right”. Until you realize the constraints that produced them.

Every system runs on limits, whether you name them or not, what’s allowed to change independently, what has to stay coupled, what the system will simply refuse to do, what trade-off you’re accepting today so you don’t have to relitigate it tomorrow. Good architecture isn’t the absence of constraints. It’s choosing the right ones, early, on purpose.

https://calpaterson.com/bank-python.html

Automation

Last Wednesday at the ING TownHall there was an interesting presentation about reducing toil, a lot of it was around automation. Next day I read this article from Austin and both events reminded me of this XKCD strip.

Austin is a Microsoft engineer and he describes what happened when he took a colleague’s advice to never do anything three times, meaning that any task performed more than twice should immediately be handed over to automation. He assumed he had very little left to automate, since most of his coding work was already delegated to AI agents, and he expected the remaining fragments to be too awkward or too specialized to bother with at all.

He was, in his own words, very wrong, and the particular way in which he was wrong is far more interesting than a simple story about a productivity gain. He automated all the obvious parts and this gain shifted the work he needs to do. It made visible all the non-parts, what he calls “the glue work that never bothered me before”.

When start hardcore automating stuff it may be a rabbit hole 🙂

https://austinhenley.com/blog/automatingmyjob.html

https://xkcd.com/1319

Towards Resiliency

This post from Amex reminded of my time at PagBank, we had a huge monolith there and we spent so much effort into converting it to a service architecture. The idea around a microservice, we all know, is about independency of the services leading to resiliency.

What makes Amex’s approach compelling is not the novelty of isolation as a concept ofc, since engineers have pursued fault containment for decades, but rather the discipline required to enforce it in practice. Cells in their design never span multiple regions, no transaction in the critical path waits on a synchronous call to another cell, and a global router sits at the edge to deterministically send each transaction to the cell that already holds the authoritative data it needs. Reference data such as currency rates and merchant category codes gets replicated into every cell well ahead of time, which means transaction processing never has to reach back to a central system of record while a customer is waiting on a response.

The trade off is honest and worth dwelling on, because cellular isolation increases operational overhead and architectural complexity, and it occasionally forces teams to duplicate services that a single shared implementation would otherwise simplify. Again, at Pagbank, we lived this, sometimes was a step back to make two upfront. For systems where the cost of a widespread outage dwarfs the cost of that added complexity, the exchange tends to be worth making, and the broader lesson generalizes well beyond the world of payments. Resiliency is rarely achieved through monitoring and retries alone, it is achieved by defining clear failure boundaries and then enforcing them relentlessly through design decisions that the rest of the organization has to live with every day.

https://americanexpress.io/cell-based-architecture-for-resilient-payment-systems

The Proof in the Code: How a Truth Machine Is Transforming Math and AI

Book recommendation: “The Proof in the Code: How a Truth Machine Is Transforming Math and AI” by Kevin Hartnett.

This is about the creation of the Z3 solver and how it drove the creation of the Lean programming language, such a fun and thoughtful reading. And the cherry on top is that Z3 was created by a Brazilian, Leonardo de Moura. In the WC mood, VAI BRASIL! 😀