API Middleware for a Global Bank
Two enterprise systems that had to talk to each other, for a client where a single failed test would have cancelled the project. Built robust first, scalable to any level, and delivered under a strict NDA.
A brief with no room for error
The client arrived with the plan already written. Two of their systems needed to communicate through a middleware application, and exactly what had to happen was specified. Our role was not to work out the what; it was to propose and build the how, and to get it right first time.
The terms were unambiguous. The system had to be extremely robust, because with a client of this size there is no tolerance for errors. It had to scale to any level without failing. And if any part of the software testing failed, the project would be cancelled.
It was delivered under a strict non-disclosure agreement, which we offer every client and which this one required. So this page stays deliberately top-level: the technology we used, the problems we solved, and a general view of what was delivered. No names, no screens.
Respecting a rate limit without making anyone wait
The hard constraint sat on one side of the bridge. One of the connected services had a known limit on how many requests it would accept per minute. Push past it and requests fail; hold everything back and the calling system sits waiting. Neither was acceptable for a client that had made robustness the condition of the project.
We solved it with queueing. Every incoming request is accepted immediately and placed in a virtual queue as a job. A separate process takes jobs from the queue at set intervals and passes them to the rate-limited service. The calling system gets an instant response; the downstream service never sees more than it can handle.
approach accept → acknowledge → queue as job → worker releases at interval
outcome immediate responses upstream · full control over requests in flight · limit never breached
Queueing also gave us something the brief did not ask for but a bank always wants: complete control. How many requests are processed, how fast, and in what order became configuration rather than chance.
It is a well-understood technique. The judgement is in knowing that it is the right one before the first test, not after the first failure.
Built to be replicated, not resized
“Scalable to any level” is decided at the hosting architecture, not in application code. A single server that gets bigger has a ceiling; a set of identical servers that gets wider does not. The application was developed inside Docker containers so that it could be replicated across many load-balanced servers, all acting as one entity.
The containers integrate with AWS’s scalable hosting, so the application is granted more resources as and when they are required and releases them when they are not. Capacity follows demand instead of being guessed at in advance.
One application on one server, upgraded when it strains and hoped-for headroom the rest of the time.
Identical containers behind a load balancer, added on demand, with no single machine the system depends on.
Testing as the gate, not the afterthought
When the brief says a failed test cancels the project, testing stops being a phase at the end and becomes the shape of the work. Every design decision above was made with the question of how it would be proven, under load, before the client ran it themselves.
The queue made behaviour under bursts predictable and repeatable rather than dependent on timing. The container architecture meant the environment tested was the environment deployed, replicated exactly. Both choices removed categories of surprise before anyone looked for them.
Alongside the engineering, the client had regular updates and transparent communication throughout. On a project with no margin, knowing where things stand is part of the deliverable.
What we can say, and what we can’t
We offer every client the option of a non-disclosure agreement, and we hold to it. For this project that means the client, the systems involved and the specifics of the integration stay confidential, and no real interface appears on this page. The illustrations above are exactly that: illustrations of the architecture, not the product.
Who the client is, which systems were connected, what the data was, what the interface looks like, the numbers behind it.
The engineering approach, the technology used, the standard it was held to, and that it is in production and supported.
If your project needs the same terms, they are available from the first conversation.
Why a bank picks a small team
The brief was clear and the standard was high, and neither of those requires a large vendor. What they require is a team that can propose a sound solution, build it without drift, and be reachable when a question comes up.
The techniques here are not exotic: a queue, containers, a load balancer. The value was in choosing them for the right reasons, implementing them so they could be proven, and delivering on time and on brief for a client who would have walked away from anything less.
The same discipline applies to a founder’s first product or an SME replacing a spreadsheet. The bank simply made it a condition.
Where it stands
The application is in production and we support it with all development updates. Business-critical changes are made without disruption to the services that depend on it, which is the point of having a technical partner rather than a one-off supplier.
It passed the test that would have cancelled it. Everything else about the project is the client’s to tell.
Need two systems to talk, reliably, at scale?
Integrations, middleware and APIs built to a bank’s standard of robustness, with an NDA available from day one if your project needs it.
.avif)
