TL;DR: a mid-sized bank that needs to launch a new product or absorb a transaction spike usually faces the same uncomfortable choice: rewrite the core, with all the cost and risk that carries, or push the problem down the road with workarounds. Amplify starts from a third path, an enterprise layer that connects to the existing core and solves what the core cannot solve on its own: horizontal scale, fault isolation and launch speed. This article describes the three technical decisions behind that, event-driven architecture, isolation by design and cloud-native auto-scaling, and what a real case showed in production.
Over a long holiday weekend, PIX volume at one of our clients doubled in just over two hours. No commercial heads-up, no planning window, just the transaction chart climbing while operations watched. The infrastructure absorbed the spike by adding capacity on its own and went back to normal afterwards, without anyone opening a ticket in the middle of the night. That is the kind of event that separates an architecture that scales from one that promises to scale, and it is what this article unpacks.
A CTO at a mid-market bank or fintech evaluating a layer on top of the core tends to ask the same question three ways: what happens when volume triples, what happens when a service goes down, and what will need to be rewritten two years from now. All three answers live in the architecture, so that is where we start.
In this article
- Why event-driven
- Fault isolation by design
- Cloud-native, to scale without a big switchover
- The real test: the transaction spike
- What a real case showed in production
- Frequently asked questions
- What this changes in the decision
Why event-driven
Amplify's most structural decision was to treat every transaction, sign-up, approval and payment as an event published in real time, instead of a synchronous call in which one service waits for another's response before moving on. That sounds like an implementation detail until you put the two models side by side.
| Dimension | Traditional monolith | Event-driven Amplify |
|---|---|---|
| Latency | 1 to 3 seconds | under 100ms |
| Scalability | Vertical, swap the server | Horizontal, add instances |
| Deploy | Everything together, everything stops | Independent services |
| Failures | Cascade effect | Isolated per service |
The drop from seconds to under 100ms does not come from optimizing code inside the monolith, because that would leave the waiting intact. It comes from eliminating blocking calls, the ones where a service sits idle waiting for another. The event bus, which on the platform runs on Apache Kafka, decouples whoever produces an event from whoever consumes it, so a slower anti-fraud service keeps its own pace without holding up the PIX queue. The latency figures above are published by the platform itself and serve as a starting point for technical due diligence, not yet confirmed as a contractual SLA.
Fault isolation by design
The question every bank architect asks is about the failure mode: what breaks first, and what happens to the rest of the system right after. In a monolith, an unhandled exception in a reporting module can bubble up and take down PIX processing, because the two share a process, memory and deploy cycle. That is the risk Amplify cuts by splitting each domain, accounts, ledger, PIX, cards and anti-fraud, into services with their own state that only talk through asynchronous messages.
The design follows the principles of the actor model: processing units with encapsulated state, no shared memory, exchanging messages instead of calling each other's functions directly. When a unit fails, the supervisor restarts only that unit and the rest of the system keeps running without noticing. That isolation is what backs the promise of contained failure and automatic recovery with no manual intervention. Whether the implementation literally uses an actor runtime or an equivalent mechanism is worth checking with the engineering team before using the analogy in a formal technical opinion.
Cloud-native, to scale without a big switchover
At Amplify, cloud-native means two concrete things. The first is infrastructure that adjusts to traffic without someone filing a ticket for more servers, with automatic provisioning as demand changes, redundancy across multiple zones and recovery within minutes. The second is an architecture of independent layers, which lets a client turn on PIX and anti-fraud without inheriting the weight of modules it does not use.
There are four layers, and each can be replaced or switched off without breaking the others.
This separation is the real technical argument against rewriting the entire core just to add a new product. It is also what backs the scale claim the platform publishes: growing from one thousand to one million accounts without refactoring the architecture, with guaranteed uptime and automatic disaster recovery. These are capabilities published by the platform itself, not measured independently for this article, and they serve as a basis for the technical evaluation of anyone considering it.
The real test: the transaction spike
The holiday scenario this article opened with is the textbook example of that test, because PIX volume can double within a few concentrated hours, without the reaction time that gradual growth allows. The mechanism that answers that spike is the same one Amplify describes for Black Friday and payroll closing: automatic horizontal scaling, where the platform adds instances as demand rises and scales them back down once the peak passes, with no manual intervention and without the degradation typical of a system sized only for average daily volume. The sustained throughput during this kind of event is a number that still needs to be documented publicly, so the PIX example stands as an illustrative scenario, not a measured benchmark.
What a real case showed in production
Away from the slide deck, the most honest test of any architecture is a project with a real deadline. Our most concrete case is one of the largest delivery platforms in Brazil, which needed full business banking for its partners, with PIX, boletos, DDA and its own digital cash management. The project went from kickoff to go-live in four months and reached 8,000 accounts in the initial rollout, with 100% BACEN PIX compliance.
The client's Head of Engineering put it this way: "We needed a decisive partner to speed up our banking product under extremely tight deadlines. Sciensa came in and moved development forward significantly, with precision, data discipline and security at every step." The numbers the platform publishes for this kind of project, 10 times faster than an in-house build, 90% fewer bugs than building from scratch and 9 times return on investment in the first 12 months, are comparisons against building the same thing internally, with the measurement methodology still to be confirmed before quoting them to a board.
[](https://amplify.finance/pt/contato?utm_source=blog&utm_medium=banner&utm_campaign=arquitetura-banking)
Frequently asked questions
Does Amplify replace core banking?
No. Amplify connects to the existing core as an enterprise layer on top of it and adds scale, fault isolation and new products without requiring a rewrite of the core. The client turns on only the modules it needs, such as PIX or anti-fraud, without touching what already works today.
How does event-driven architecture reduce latency?
It eliminates synchronous calls, the ones where a service sits idle waiting for another's response. Every transaction becomes an event published in real time on a bus, and services consume it at their own pace. The platform reports latency under 100ms, a figure worth confirming under peak load.
What happens if one of the bank's services goes down?
Each domain, such as PIX, cards or anti-fraud, runs in isolation, with its own state and communication only by message. When a service fails, the supervisor restarts only that service and the rest keeps operating. A failure in reporting does not take down payment processing, because the two share neither process nor memory.
Can Amplify handle a holiday PIX spike?
The design includes automatic horizontal scaling: the platform adds instances as demand rises and removes them when the peak passes, with no manual intervention. It is the same mechanism used for Black Friday and payroll closing. Exact peak throughput is still a number to confirm with engineering.
How long does it take to launch a new banking product?
It depends on scope. The most concrete public case was full business banking taken from kickoff to go-live in four months, with PIX, boletos, DDA and its own digital cash management. The modular architecture lets you turn on products without rewriting the core, which shortens the time between decision and launch.
What this changes in the decision
For anyone evaluating this layer, the right technical question goes beyond whether Amplify is fast. It calls for three concrete answers: whether the architecture isolates the risk of one domain, like PIX, from the risk of another, like reporting; whether the system scales horizontally without depending on a manual infrastructure event; and whether compliance such as LGPD, BACEN and PCI DSS is built into the design of each module rather than patched on later. On all three, the documented answer is yes, with the measurement caveats this article has made explicit.
A serious architect's next step takes more than trusting an article: it means seeing the architecture run with your own transaction volume. Talk to a Sciensa specialist and schedule a technical demo of Amplify with your operation's load scenario.