Hybrid Cloud Banking Architecture: ~400K Users, Seven Banks, Zero Downtime

Executive Summary

How Did a Central African Consortium Deploy a Hybrid Cloud Banking Architecture with Zero Downtime?

A leading financial services consortium in Central Africa – seven banks operating under a single umbrella – needed a next-generation internet banking platform that was scalable, secure, and adaptable enough to fit every bank in the group. The requirement was concrete: a hybrid deployment that kept sensitive workloads on on-premises infrastructure while using public cloud for the workloads that didn’t need to live behind a bank’s perimeter, an API layer that could plug into diverse Core Banking Systems, and a white-label surface flexible enough to onboard new banks without a codebase fork. This case study walks through how Teamvoy designed and delivered that hybrid cloud banking architecture. VMware ESXi on BareMetal ran the critical operations on Linux VMs; public cloud absorbed non-critical services; Docker containerized everything; a Lift & Shift approach migrated the legacy footprint fast and with minimal disruption; an API Gateway with per-CBS adapters kept every partner bank’s Core Banking System integrable; a BFF layer separated the presentation logic from the microservices underneath; and a CI/CD pipeline with Snyk security scans plus ESLint and Prettier quality gates kept releases clean. The result: ~400,000 B2C users on one platform, and zero-downtime updates across the consortium.

01. Our Client

Who Is the Client, and Why Does Hybrid Cloud Internet Banking Fit This Consortium’s Reality?

The client is a leading financial services company operating in Central Africa, part of a consortium managing seven banks. The mandate was to deliver a next-generation internet banking platform that was scalable, secure, and adaptable enough to work across the entire group: consumer and business banking on one foundation, integrated with each bank’s Core Banking System (CBS), and configurable per bank without diverging codebases.
Hybrid cloud internet banking was not a stylistic choice for this consortium – it was the only architecture that satisfied all three pressures at once. Critical banking workloads had to stay under direct control on-premises. Non-critical workloads needed the cost profile and elasticity of public cloud. And the whole thing had to onboard new banks quickly enough that the platform actually paid back the investment. Teamvoy was hired to build the architecture that put those three properties in the same system.

02. The Challenge

What Has to Be Solved Before a Scalable Banking Platform Can Ship?

Five architectural challenges defined the baseline. Each one is common in group banking; together they compress into an unforgiving design brief.

Hybrid deployment. On-premises infrastructure had to handle the critical operations; public cloud had to absorb non-essential workloads. The two environments had to communicate cleanly, at low cost, without either becoming the reliability ceiling for the other.

Flexibility and scalability. The platform had to handle variable user demand across seven banks, onboard new banks or regions without rebuilding anything, and support updates and enhancements without disrupting live service.

CBS integration. Partner banks run different Core Banking Systems, including legacy ones. The platform needed a robust API Gateway and middleware supporting all of them, with real-time data synchronization.

Security and compliance. Advanced data encryption at rest and in transit, multi-factor authentication, regional banking regulatory compliance, and a disaster recovery strategy that could survive infrastructure loss without visible impact on end users.

Customization and white-labeling. Partner banks had to be able to change branding, user experience, and feature scope quickly, without technical involvement, and without weakening security or performance for the others sharing the platform.

03. Why This Approach

Why Hybrid Cloud + Banking Microservices Architecture?

A hybrid cloud banking architecture is one that combines on-premises infrastructure – typically BareMetal, sometimes virtualized – with public cloud services, drawn around what the data and workloads actually require. The category exists because pure-cloud banking is politically and regulatorily hard, and pure-on-premises banking is economically and operationally hard. Hybrid is the answer both to “where does sensitive data belong?” and to “how do we not pay for elasticity we don’t need?”

For this consortium, three architectural properties made the project viable. Banking microservices architecture split individual capabilities into independently deployable services, so features could ship and scale without touching the rest of the system – and one bank’s release couldn’t break another’s. Hybrid deployment put critical workloads on BareMetal with VMware ESXi and Linux VMs, and moved non-critical ones (customer success tools, video conferencing, support tooling) into public cloud. And Docker containerization made workloads portable across both sides of the hybrid line, so the deployment model stayed flexible rather than becoming its own vendor lock-in.

The deeper reason this worked is that it drew a clean line between data, environments, and lifecycle. Sensitive data stayed on-premises, elastic workloads went to cloud, and the same containerized services moved cleanly between them. That separation is what made zero-downtime updates possible: no update ever had to touch every layer at once.

04. Solution

How Did Teamvoy Build the Hybrid Cloud Banking Architecture?

The engagement delivered five interlocking workstreams: the hybrid deployment model, a Lift & Shift migration of the legacy footprint, the CBS integration layer, the BFF + microservices application architecture, and a CI/CD pipeline with security and code-quality gates baked in.

Hybrid deployment. VMware ESXi hypervisor runs on BareMetal servers (Dell / HP) hosting Linux-based VMs for critical banking operations – chosen for efficient isolation, minimal latency, and end-to-end control over sensitive components. Non-critical workloads (customer success tools, video conferencing, support systems) sit on public cloud to keep costs down and reduce operational overhead. Docker containerization makes workloads portable across both sides of the hybrid line.

Lift & Shift migration. The legacy footprint was migrated to the new hybrid infrastructure by replicating the existing environment with minimal modifications first – a fast, low-disruption move that preserved the integrity of legacy applications. Cloud-native optimizations followed over time, once the migration was stable, unlocking additional performance and cost efficiency without ever having taken the platform down to get there.

CBS integration through an API Gateway and per-CBS adapters. An API Gateway sits at the primary interface between the platform and external systems, handling secure real-time data synchronization and integration with third-party services (payment processors, regulatory reporting tools). Per-CBS API adapters absorb each partner bank’s unique requirements, so the integration surface stays stable regardless of what a given bank runs underneath – legacy or otherwise.

BFF + microservices application architecture. A Backend-for-Frontend layer streamlines communication between the presentation layer and the underlying services, delivering a responsive UI without coupling the client tightly to the service topology. Underneath, a microservices architecture splits the platform into self-contained modules with independent deployment and elastic scaling, so features and load can move at different speeds. The presentation layer itself was built with accessibility as a first-class concern – text-to-speech, adjustable font sizes, intuitive navigation.

CI/CD with security and code-quality gates. A structured branching strategy separates feature development, pre-release testing, and production readiness. Semantic release tools automate versioning and changelog generation. The pipeline runs Snyk for security scanning and ESLint + Prettier for code quality on every change, so no release reaches production without passing both. Regular disaster recovery drills across geographically distributed data centers keep the failover posture from becoming theoretical.

Tech Stack

Which Technologies Power the Platform, from CBS Integration to CI/CD?

• VMware ESXi hypervisor on BareMetal servers (Dell / HP) – the runtime for critical banking workloads on Linux-based VMs.
• Docker – containerization for portability across on-premises and public cloud environments.
• Java 21 + Spring Boot – runtime for the microservices making up the platform.
• Spring Data JPA, MapStruct, Lombok – persistence, mapping, and boilerplate-reduction across the service layer.
• PostgreSQL 16 + Liquibase – relational store with version-controlled schema migrations.
• Redis – caching and high-throughput data access.
• JUnit, WireMock, Testcontainers, Instancio – test pyramid covering unit, integration, and contract testing with real dependencies in containers.
• API Gateway + per-CBS API adapters – secure real-time integration with heterogeneous Core Banking Systems and third-party services.
• BFF (Backend-for-Frontend) layer – optimized communication between the UI and the microservices underneath.
• Snyk – security scanning on every CI/CD run.
• ESLint + Prettier – code quality gates on every pull request.
• Semantic release tooling – automated versioning and changelog generation.

Key Features

Which Features Define This Architecture, from BFF Layer to CI/CD Pipeline?

• Hybrid deployment splitting critical workloads onto BareMetal + VMware ESXi + Linux VMs, and non-critical services onto public cloud.
• Containerized workloads (Docker) portable across on-premises and public cloud without rewrites.
• Lift & Shift migration approach for legacy systems: fast, low-disruption first, cloud-native optimization second.
• API Gateway plus per-CBS adapters enabling seamless integration with heterogeneous Core Banking Systems and third-party services.
• BFF layer optimizing communication between the presentation layer and the microservices underneath, plus an accessibility-first UI (text-to-speech, adjustable font sizes, intuitive navigation).
• Microservices architecture with independent deployment and elastic scaling on demand.
• Structured branching strategy plus semantic release tooling for consistent, transparent versioning.
• CI/CD with Snyk security scanning and ESLint + Prettier code quality checks on every change.
• White-label UIKit letting partner banks customize theming, logo, and UI components without technical involvement.
• Security baseline: TLS/SSL encryption at rest and in transit, MFA, regular compliance audits and penetration tests.
• Geographically distributed data centers with a rehearsed disaster recovery strategy, tested through regular drills.

Key Engineering Decisions

Which Engineering Decisions Kept the Platform at Zero Downtime?

Five decisions shaped the platform’s behavior under group-scale load. Together they are the reason zero-downtime updates are a property of the architecture rather than a policy.

Draw the hybrid line around the data, not around fashion. Critical banking workloads run on-premises on BareMetal + VMware ESXi + Linux VMs, where the consortium and its regulators want them. Non-critical workloads sit on public cloud for cost and elasticity. The decision wasn’t “cloud vs on-prem” – it was which workloads belonged where, based on sensitivity and reliability requirements.

Containerize everything, then treat the deployment model as portable. Docker makes services move cleanly between on-premises and public cloud without rewrites. That portability is what makes hybrid cloud a genuine architecture instead of a diagram – workloads can shift between sides of the hybrid line as requirements evolve, without the platform having to be rebuilt around each shift.

Lift & Shift first, optimize second. The legacy migration ran with minimal modifications first, so the platform got to a stable hybrid state fast. Cloud-native optimizations followed once the migration was safe. That ordering is what kept the migration from becoming an outage; refactoring during a lift-and-shift is how these projects typically stall.

One API contract, many CBS adapters. The platform exposes a stable middleware contract; per-CBS adapters underneath absorb the differences between partner banks’ Core Banking Systems. Onboarding a new bank does not fork the platform – it adds an adapter. That is what keeps the codebase from accumulating one long-lived branch per member of the group.

BFF layer between UI and microservices. A Backend-for-Frontend sits between the presentation layer and the services, aggregating and shaping data for the UI. The client stays decoupled from the service topology, and changes to microservices don’t ripple into every screen. That decoupling is what lets microservices evolve on their own timelines without dragging the UI along.

05. Impact

What Impact Did the Hybrid Cloud Banking Architecture Have on the Consortium?

The architecture delivered the consortium’s core mandate: all seven banks under the group launched a unified but customizable internet banking solution on one platform, and the platform now serves approximately 400,000 B2C users with the scalability and performance the group projected at kickoff. The hybrid deployment model reduced operational costs materially compared with a pure on-premises or pure cloud alternative, and the CI/CD posture – containerization, structured branching, semantic releases, Snyk + ESLint + Prettier gates – lets updates ship with zero downtime for end users.

Underneath the user-visible delivery, security, compliance, and disaster recovery moved from documented intentions to tested properties. Geographically distributed data centers, MFA, TLS/SSL, and regular DR drills give the consortium a posture that stands up to real regulatory scrutiny.

The broader payoff is architectural. The platform’s constraints stopped being “where can we deploy” and “how do we integrate the next CBS” and became “what should we ship this quarter.” That is the right constraint to be facing for a group banking product at this scale.

Lessons Learned

What Should Banking Groups Know Before Adopting a Hybrid Cloud Banking Architecture?

A few takeaways generalize beyond this engagement and apply to any banking group weighing a shared, hybrid-cloud internet banking platform.

Draw the hybrid line around sensitive data. The right question is not “cloud or on-premises” but “which workloads belong where.” Sensitive banking workloads on BareMetal, non-sensitive ones on public cloud, containerized services moving between them. That framing produces a durable architecture; “cloud-first” or “cloud-never” both produce brittle ones.

Lift & Shift before you optimize. Every legacy migration is tempted to rewrite along the way. Don’t. Get to a stable hybrid footprint first, then optimize for cloud-native features. Refactoring during migration turns a two-phase project into a single high-risk one.

One API contract, many CBS adapters. Partner banks run different Core Banking Systems, and their choices will change over time. A stable middleware contract with per-CBS adapters underneath is what keeps the platform from being rebuilt every time a member of the group swaps its core.

BFF layer, not direct UI-to-service coupling. In a microservices banking platform, the UI will change faster than the services, and the services will change on their own schedules. A Backend-for-Frontend layer between them is what keeps both sides able to move without dragging the other along.

Zero downtime is a property of the pipeline, not a policy. Containerization, structured branching, semantic releases, and security + code-quality gates in CI/CD are what make zero-downtime updates a real property of the architecture. It is not achievable by carefully scheduling maintenance windows.

06. Conclusion

Where Should Banking Groups Start with Hybrid Cloud Internet Banking?

For this consortium, the hybrid cloud banking architecture was less about picking a stack and more about giving seven banks one place to launch, brand, and operate a modern digital experience without seven separate architectures. The BareMetal + public cloud split, the microservices application layer with a BFF in front, the API Gateway with per-CBS adapters, and the CI/CD pipeline with Snyk + ESLint + Prettier gates turned a challenging design brief into a shippable platform – ~400,000 users, zero-downtime updates, and a release cadence all seven banks share.

If you are evaluating hybrid cloud internet banking for a banking group, the most important question is not “which cloud provider or framework should we pick?” – it is “how do we deploy sensitive workloads where they belong, keep the rest elastic, integrate multiple Core Banking Systems without forking the platform, and update production without anyone noticing?” The answer is usually the hybrid architecture, drawn around the data.