How these systems are actually shaped

Options considered

• rejectedA shared client with per-provider configConfiguration cannot express semantic differences. One provider's success means settled, another's means accepted. That is code, not a config key.
• chosenAn adapter per provider, owning its own mapping, timeouts and error translationOnboarding the ninth bank requires no reasoning about the first eight, and one misbehaving provider stays contained instead of becoming a platform incident.

Consequence accepted

More code, and deliberately so. The duplication buys isolation: per-provider circuit breaking becomes possible, and each adapter declares its provider's semantics in a place an engineer will actually read.

Grounded in, Led backend development of the FIAP Transfer Service (Java, Spring Boot) across 8+ partner banks.

Options considered

• rejectedTwo outcomes, success and failureForces the system to guess on timeout. A wrong guess in a financial system is worse than no record at all.
• chosenThree outcomes, with an active resolution path for the thirdThe transaction's lifecycle outlives the request that started it, so something has to own it afterwards: polling, callback handling, reconciliation.

Consequence accepted

A transaction is not done when the request returns. That shapes the whole service: status endpoints, bounded polling with backoff, and reconciliation as a first-class feature rather than an operations script.

Grounded in, Streamlined financial transfer operations across 8+ partner banks; integrated MTN Mobile Money into the B2B middleware.

Options considered

• rejectedOne service, one store, both query typesDifferent latency tolerances and access patterns. The analytical query eventually degrades the operational one, usually under load.
• chosenA dedicated reporting service alongside the aggregation platformSomeone will run an unbounded query against production data. Better that they do it somewhere that cannot affect a transfer.

Consequence accepted

An extra service to operate, and an explicit consistency window between the two paths, which has to be stated rather than discovered by whoever reads the numbers.

Grounded in, Built and maintained the Biller Aggregation Platform (BAP) and its companion BAP Reporting Service (BRS) in Node.js and Java/Spring Boot.

Options considered

• rejectedLoad the model in the application processCouples model updates to application deploys, and puts inference memory and latency inside the request-serving process.
• chosenA serving layer with its own scaling and timeout profileInference becomes an operable dependency: versioned, independently scaled, and with a defined answer to “what does the page do when the model is slow?”

Consequence accepted

A network hop and a degraded path to design. The page has to render something useful when inference times out. That is the cost of not having an untestable model inside the app.

Grounded in, Implemented an ML model to predict user engagement and optimised inference using TensorFlow Serving.

Options considered

• rejectedSplit first, automate delivery laterServices you cannot deploy separately are a monolith with extra network calls. All of the cost, none of the benefit.
• chosenContainerise and automate the path to production first, then draw boundariesIndependent deployment is what makes a boundary real. Owning the pipeline also changes how many boundaries you draw, usually fewer, and better ones.

Consequence accepted

Slower to the first service, faster to the third. The pipeline is what decides how often a team can safely change its mind.

Grounded in, Architected in-house backend microservices in PHP and set up CI/CD, Dockerisation and AWS S3 storage for the platform.