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

I love December. Christmas, New Year, a week or 2 holidays, a look back at the year’s achievements and… AdventOfCode. AdventOfCode is an annual programming challenge consisting of puzzles that can be solved in any programming language. The event is aimed at people with different levels of programming skills and offers an opportunity to improve our skills and learn new techniques. Challenges are launched daily during the month of December until the 25th, at Christmas. There are always 2 problems and for each one solved you get a star.

I’ll be honest and say that until 2022 I solved some challenges but I was never consistent. This year I decided to take it seriously and by the 8th I had collected all 16 stars. And as I said above, I’m seeing it as a learning opportunity: every problem has an example with a solution, so here I am doing TDD, the classic red-green-refactor cycle; every day you download a text file as input and solve for each of the stars, so here I am with an automated template in node that generates a common structure of files and folders; Problems can be solved in several ways, so here I am calculating the performance of my solution and optimising; I’m publishing my answers day by day, so here I am commenting on my code so that my intentions are clear; As there is one issue per day, so here I am looking at each day as a release, I automated the generation of releases on Github using release-please.

My strategy every day has been the most naive, I try to solve everything by brute force. When it takes too long, I stop and think of something better. If it’s acceptable (well, it’s quite subjective here, anything running in less than 3 minutes, ok), I send the answers and at the end of the day I revisit the problem and reflect on whether there’s a better way to do it. For example, one day it was necessary to calculate paths using a map with instructions. My first approach was with a loop, after solving it I realised that I could use the least common multiple of the different paths. Nice!

Let’s see if I can keep up with the issues, it’s been a lot of fun, I highly recommend it!

After returning from API Days in London, I’m studying design patterns for APIs. The last paper I read was “Arguments and Results” by James Noble (1), published in 1997 and still extremely relevant. Part of my current work, developing a data warehouse, is to optimize the transport of huge volumes of data. And if I want to use APIs, how can I do this efficiently? There is a consensus that REST API’s are not suitable in high-volume scenarios and studying this topic I arrived at Noble.

The article discusses patterns for object protocols and for this there are two groups:

• How to send objects (Arguments): Arguments object, Selector object and Curried object

• How to receive objects (Results): Result object, Future object and Lazy object

Patterns

• Arguments object: This pattern is utilised to streamline a method’s signature by consolidating common arguments and objects, and modifying the method signature to accept this consolidated object instead. It brings several advantages, you make your domain explicit; your customers can use what they have at hand (the objects, instead of separated values); and you are able to separate the processing logic from your business logic

From

    void Send-FixedIncome(EntityName, IssueDate, MaturityDate, PrincipalAmount, ...) { }

To

    void Send-FixedIncome(FixedIncome) { }

“adding an eleventh argument to a message with ten arguments is qualitatively quite different to adding a second argument to a unary message”

• Selector object: When you have methods with quite similar arguments, this patterns introduces a selector that enables you to pick one of them. Noble mentioned you could a enum, maybe using GoF a Flyweight would do the trick.

From

    void CalculateHomeLoanAmount(HomeLoan, Collateral) { }
    void CalculateHomeLoanAmount(HomeLoan) { }
    void CalculateAutoLoanAmount(AutoLoan) { }
    void CalculatePersonalLoanAmount(PersonalLoan) { }

To

    void CalculateAmount(LoanType, Loan) { } //Loan would be the interface for all loan types

“Protocols (APIs) where many messages perform similar functions are often difficult to learn and to use, especially as the similarity is often not obvious from the protocol’s documentation”

• Curried object: from the functional programming world, currying breaks a function with several arguments into smaller functions, where each one of those functions takes some (usually one) of the original arguments; these functions are called in sequence then. Noble introduces this pattern for a scenario where the caller should not need to supply all arguments (e.g. constants), the method can supply on their behalf. In GoF terms, it acts as a proxy.

From

    void SettleDebt(Loan, ParcelsToPay) { } # no. of parcels can be retrieved from the loan 

To

    int GetOpenParcels(Loan) { }
    void SettleDebt(Loan) { () => Settle(Loan) } # in Settle no. of parcels is retrieved

“These kinds of arguments increase the complexity of a protocol. The protocol will be difficult to learn, as programmers must work out which arguments must be changed, and which must remain constant.”

• Results object: For complex scenatios, one might need several method calls to generate the expected result. Your results object should be a single one with everything on it. This pattern can be seen as the flip side of the Curried Object pattern. One aspect worth mentioning is when those several calls mean several systems. In this case. a result object helps to reduce the coupling and acts as an abstraction around them.

“Perhaps the computation returns more than on object”

• Future object: This pattern is employed when we need to execute a time-consuming operation and perform other tasks while waiting for the operation to complete. In essence, we aim to process a result asynchronously and then likely invoke a callback upon completion.

” Sometimes you need to ask a question, then do something else while waiting for the answer to arrive”

• Lazy object: Sometimes you need to supply a result, though it is not 100% sure whether the method will be called. The advantage of this is that we don’t get data unnecessarily.

“Some computations can best be performed immediately but the computation’s result may never be needed”

All in all, these concepts are quite widespread. Any mainstream programming language has support for async methods (Future object) and lazy evaluation (Lazy object). Moreover, good OO design makes ‘Arguments object’ and ‘Seletor object’ quite naturally appear. Even though it was a good back-to-basics article to remind me the importance of good design in my API methods.

(1) https://www.researchgate.net/publication/2733549_Arguments_and_Results