A normal web application can survive an awkward minute of downtime. A digital banking platform cannot. When a customer cannot log in to check a balance, cannot submit a payment, or cannot see the transaction that just left their account, the trust the bank has spent years earning is debited in seconds. The infrastructure beneath a digital bank is the trust layer, not just the hosting layer. Our team treats it that way from the first whiteboard session.
When our consultants designed the platform architecture for a digital bank on Huawei Cloud, the priorities were clear before any specific service was named: the system had to be secure by default, highly available across faults, scalable as transaction volume grew, and cost-disciplined so the operating cost did not run ahead of the platform’s revenue trajectory. Every architectural choice in the design below is anchored to one of those four priorities — not to a preferred vendor catalogue.
- Digital banking infrastructure is the trust layer of the bank, not just the hosting layer. Every architectural choice should map back to availability, security, scalability, or cost discipline.
- Traffic enters through an Elastic Load Balancer rather than directly hitting application servers, so a single unhealthy node never becomes a single point of customer-facing failure.
- The application and database layers are isolated inside a Virtual Private Cloud, with the database deliberately placed where the public internet cannot reach it.
- Security is designed as layers — Security Groups, controlled SSH access, host protection, key management, and web application firewall — not as a single perimeter.
- The platform is sized to launch lean and scale up as transaction volume justifies it, so the bank does not pay for capacity it has not earned.
Why E-Banking Infrastructure Cannot Be Designed Like a Normal Web App
The difference between a normal web application and a digital bank is not how many users connect at once. It is what each connection means. A retail website that drops a session has lost a basket. A digital bank that drops a session may have lost a payment instruction halfway through transmission, or may have shown a customer a stale balance just before a transfer. The cost of a bad minute is denominated differently. The architecture has to reflect that the things flowing through it are obligations, not impressions.
For our consultants, that translates into a small set of design rules that our team carries into every fintech infrastructure engagement. The system must remain available when individual components fail, not only when the cloud region is healthy. Customer-facing services must not be one configuration mistake away from public exposure. The database that records transactions must outlive the application servers that talk to it. And the entire posture should be auditable in language that the bank’s compliance team can defend, not just operate.
The Architecture, in Plain Terms
The user journey through the architecture begins on the public internet. Customers and internal staff reach the platform through a domain mapped to an Elastic Load Balancer (ELB), which is the only public entry point our team exposes. The ELB does two jobs that matter to the bank long before they matter to the engineering team: it hides the application servers behind a single addressable surface, and it watches the health of every node it serves so traffic can move away from failure within seconds.
Behind the ELB sits the application layer — a fleet of Elastic Cloud Servers (ECS) hosted inside a Virtual Private Cloud (VPC) in the AP-Kuala Lumpur-OP6 region. These instances are sized at 8 vCPUs and 16 GB of RAM, which our team selected as the working baseline for the kinds of workloads digital banking generates: API calls, session orchestration, dashboard rendering, batch transaction processing, and the steady background of authentication and authorisation checks. The application servers are distributed across more than one subnet, so a subnet-level fault does not take the whole banking service offline.
The transactional database lives on Huawei Cloud RDS MySQL, deliberately placed in a recovery subnet that the public internet cannot reach. Application servers talk to the database over private networking. The database is treated as the system of record — the place where the bank’s obligations are written down — and it is therefore the most carefully protected resource in the design.
Around all of this sit the controls that make the platform defensible: Security Groups acting as virtual firewalls, an Elastic IP giving the platform a stable public address, and a recommended layer of additional security services — Host Security Service (HSS), Key Management Service (KMS), and Web Application Firewall (WAF) — that our team recommends switching on before live customer launch.
Designing for Availability: No Single Point of Customer-Facing Failure
Availability is the architectural property a digital bank’s customers feel most directly, and it is also the easiest one to get wrong by accident. A common mistake we see in early-stage digital banking deployments is treating high availability as a database problem. Our team treats it as a system property — designed into the network, the application layer, and the recovery posture together, not bolted on as an afterthought.
Why traffic enters through a load balancer, not an application server
The ELB exists to prevent any single application server from becoming the bank. When the load balancer performs its health checks and decides that an ECS instance is failing, it redirects traffic to a healthy node automatically. The customer trying to log in at that exact second does not see a failure page; they see a slightly delayed response, and the operations team sees an alert. This is the difference between a degraded minute and a public incident.
Without an ELB in front of the application layer, every published URL is bound to a specific server. When that server is unhealthy, the bank either reroutes customers manually or accepts the downtime. With the ELB in place, the failure becomes an internal event rather than a customer-facing one.
Why the application layer spans multiple subnets
The ECS application servers are distributed across separate subnets — one or more dedicated to production traffic, and one held in reserve for recovery. The production instances handle live traffic. The recovery instance is the platform’s answer to the question “what happens when an entire subnet has a bad day?” The ELB’s view of the world spans those subnets, so when an instance or a subnet drops out, traffic redirects without manual intervention. A small but real recommendation our team made on the design diagram was to rename the duplicate subnet labels into clearer names — Subnet A — Production, Subnet B — Production, and Subnet C — Recovery — so the architecture is legible to both technical and non-technical stakeholders during compliance review.
Why an Auto Scaling Group is wired in from day one
Banking traffic is not flat. Payroll days, salary credit windows, and end-of-month settlement runs all create predictable spikes; product launches and promotional campaigns create unpredictable ones. The Auto Scaling Group lets the platform add ECS instances behind the ELB when traffic climbs, then release them when traffic settles. The result is that the platform does not need to be sized for peak from day one — it can be sized for the realistic working load and scaled on demand, which feeds directly into cost discipline later in this article.
The Application Layer: Where Banking Logic Lives
The Elastic Cloud Servers are the working heart of the platform. The bank’s backend services, API endpoints, business logic, internal admin panel, and transaction-processing routines all run here. The 8 vCPU / 16 GB sizing our team selected is not a default — it is the level at which the kind of work a digital bank actually does (frequent database access, secure API exchange, user authentication, reporting, and transaction handling) runs comfortably without artificial throttling.
What matters for a banking workload is not raw CPU, it is the combination of strong network bandwidth and consistent I/O performance, because the application layer spends most of its life talking to the database and to upstream services rather than computing in isolation. The ECS profile chosen for this design reflects that. As the platform’s usage profile matures, the sizing can be revisited — our team treats the initial specification as a working starting point rather than a permanent commitment.
The cheapest mistake in cloud sizing is over-provisioning at launch. The most expensive one is under-provisioning at launch and discovering it during the first real traffic spike. The Auto Scaling Group is what makes the first mistake unnecessary — the platform can start at a realistic working size and grow into the spikes rather than paying for them in advance.
The Database Layer: Reliability Beats Configurability
A digital bank’s database is the place where customer balances, transaction histories, account information, audit logs, and operational records actually live. Almost every meaningful action the customer performs — login verification, balance enquiry, transfer submission, transaction history retrieval, internal approval — depends on it. Our team’s view is that the database layer is the wrong place to be clever. It needs to be reliable, supported, and boring in the best sense of the word.
The design uses Huawei Cloud RDS MySQL rather than a self-managed MySQL instance on a generic ECS server. The trade-off is intentional. Self-managing the database gives the engineering team more configuration freedom; using the managed service gives the bank better baseline reliability, less operational toil, and a clearer audit story when regulators ask how backups, patching, and failover are handled. For a digital banking platform at first deployment, the managed-service trade-off is the right one nearly every time.
The RDS MySQL instance is placed in a recovery subnet that is not addressable from the public internet. The application servers reach it over private networking, but no public client can. This is one of the most important security boundaries in the entire design: the database that holds the bank’s obligations is not reachable from the open internet, full stop.
Security Designed as Layers, Not as a Perimeter
The most common security mistake we see in early digital banking deployments is treating the perimeter as the strategy. A digital bank that depends on its outer firewall to keep it safe will eventually meet an adversary who is already inside that perimeter, and the design has nothing else to fall back on. Our team designs security as a sequence of layers, each of which the platform survives even if the layer above it failed.
The Security Group as a virtual firewall
Every ECS instance sits behind a Security Group that controls which inbound and outbound traffic is allowed. For a digital banking platform, these rules are written tightly by default. Public web traffic on ports 80 and 443 reaches the platform only through the ELB. SSH access on port 22 is restricted to specific administrator IP addresses, not opened to the world. Database access on port 3306 is allowed only from the application subnets, never from the public internet. Internal service ports are reachable only inside the private network. The principle is simple: every port that is open should have a documented reason for being open, and every port without a reason should be closed.
Controlled remote access without unnecessary VPN complexity
The original brief proposed Huawei Cloud VPN for administrator access. Our team’s recommendation, after looking at the actual access pattern, was different. Huawei Cloud VPN is IPsec-based, which fits a site-to-site scenario — connecting an office or data centre into the VPC — rather than the client-to-site scenario typically needed for individual developer or administrator access. For the first phase of deployment, a Security-Group-based approach (SSH allowed only from trusted administrator IP addresses) gives the bank tight access control without committing to VPN infrastructure that is not yet justified by the access model. The VPN posture can be revisited later as the team grows or as a customer-facing private network becomes part of the architecture.
Host, key, and application security as production hardening
Beyond the network controls, our team recommends three additional Huawei Cloud security services as production hardening before live customer launch. Host Security Service (HSS) monitors the ECS instances themselves — detecting intrusions, malware, vulnerabilities, and suspicious behaviour at the host level, which is the right layer to catch threats that have made it past the network controls. Key Management Service (KMS) manages encryption keys for sensitive information at rest, including database encryption and application secrets; in a banking context, key management is one of the compliance conversations regulators will want documented. Web Application Firewall (WAF) sits in front of the web and API surface and filters out the common attack patterns — SQL injection, cross-site scripting, malformed requests — that any internet-facing financial service will see attempted against it the moment it goes live.
The Elastic IP and the value of a stable address
The architecture also includes an Elastic IP to give the platform a consistent public address. This is the address the bank’s domain name maps to, the address external integrations register against, and the address the operations team writes into firewall rules at partner systems. The point is not the IP itself — it is the stability. As the backend infrastructure flexes underneath, the public-facing address remains the same, which keeps DNS, integration agreements, and partner-side firewall rules from becoming a moving target.
Designing for Cost: Start Lean, Scale on Evidence
The cost posture our team recommended for the platform is the same one we recommend for almost every digital banking first launch. Begin with a sizing that comfortably handles the realistic working load of the early customer base, rather than the peak load the bank hopes to reach by year three. Use the Auto Scaling Group to absorb spikes as they actually arrive. Keep the optional security services (HSS, KMS, WAF) as deliberate switch-on decisions tied to launch readiness, not as Day 1 default spend.
This approach has one strategic effect that matters more than the immediate cloud bill: it keeps cloud spending tied to evidence about how the platform is actually being used. As transaction volume grows, ECS specifications can be upgraded, RDS performance tiers can be increased, additional application servers can be brought online, backup strategy can be strengthened, and advanced security services can be enabled. None of those decisions need to be made before there is data to justify them. The architecture is shaped so that growth is a configuration event, not a re-architecture event.
What This Architecture Lets the Bank Do
The architectural choices above are not interesting on their own. They are interesting because of what they let the bank do day to day, and what they prevent from happening on the worst day. From the bank’s operating perspective, the design produces four outcomes our team considers non-negotiable for a digital banking platform:
- Customer-facing services remain reachable when individual servers, subnets, or even partial failures occur, because the ELB and the multi-subnet ECS layer carry traffic around the failure rather than failing along with it.
- The transactional database is never directly addressable from the public internet, which removes an entire category of attack and an entire category of compliance conversation.
- The platform’s capacity grows as the customer base and transaction volume grow, without re-architecting the application layer — the Auto Scaling Group and the ELB absorb that growth as a configuration change.
- The security posture is layered rather than perimeter-based, so the bank does not depend on a single control to hold the line.
For the leadership team, these are not technical wins. They are business outcomes — the kind that get described in board updates as “the platform held up,” “the regulator is comfortable with our infrastructure posture,” and “we did not have to rebuild the system to handle the new product line.” That is what good banking architecture is supposed to deliver.
The Closing: Architecture Is the Bank’s Trust Layer
The architecture our team designed is not the most expensive option the bank could have chosen. It is the option whose every design decision is defensible against a single question: how does this choice contribute to availability, security, scalability, or cost discipline? Every component in the architecture answers that question. Every optional service deferred to launch readiness answers it too — we did not add complexity that the platform had not yet earned the right to need.
For the first phase, the platform can launch on a deliberately practical footprint and grow into its potential. As the bank matures, additional layers — deeper WAF rules, more aggressive HSS policies, KMS-backed encryption across more services, monitoring and alerting, formal backup and disaster recovery procedures, and the compliance documentation that accompanies regulated operations — can be brought online in sequence rather than all at once. Our team’s view is that a digital banking architecture should be ready to grow into its responsibilities. This one is.