Wonderlend Hubs

Schedule a Demo
Compensation Management

From Monolith to Serverless: WonderLend Hubs’ Journey to NoCode Financial Technology Infrastructure-as-a-Service

Every technology company has an infrastructure story. Only a few have a genuine platform turning point.

At WonderLend Hubs, our move to serverless was not just a cloud-modernization exercise. It was the outcome of a deeper architectural evolution in how we think about complex financial technology systems.

Our journey unfolded in three broad phases:

Phase 1: Single-tenant monolithic systems on EC2 / Auto Scaling

Phase 2: Multi-tenant microservices on EC2 / Auto Scaling

Phase 3: Multi-tenant, domain-driven, serverless microservices using ECS/Fargate and Lambda

Each phase solved meaningful problems as well as revealed new constraints.

What eventually emerged was not merely a different deployment model, but a different platform philosophy: NoCode financial technology infrastructure-as-a-service.

Phase 1: The Single-Tenant Monolith Era

Like many enterprise platforms, we began with a more traditional model: single-tenant deployments with a monolithic application stack hosted on EC2 and scaled using Auto Scaling Groups.

At that stage, this architecture was entirely rational. It gave us control, predictability, and a straightforward way to deliver mission-critical financial workflows for clients. But over time, the limitations became clearer.

A single-tenant monolith tends to create tighter coupling across modules, slower release cycles, heavier regression overhead, duplication across client-specific deployments, and an increasing dependence on engineering teams for every meaningful change.

In BFSI platforms, that pain compounds quickly. Products evolve. Commission logic changes. Lending policies change. Distribution structures change. Regulatory requirements shift. Workflow variants multiply.

The cost of change starts rising faster than the value of change. That was the first signal that the future would require more than incremental refactoring.

Phase 2: Multi-Tenant Microservices on EC2 / ASG

The next leap was to move toward a modular, multi-tenant microservices architecture while still operating on EC2 / Auto Scaling foundations.

This phase mattered because it created clearer separation between: business capabilities, service boundaries, tenant-aware architecture, and platform scalability concerns.

It brought several advantages too like better modularity, more independent service evolution,

improved scalability, and a stronger foundation for platform thinking. But while this was a major architectural improvement over the monolith, it still carried a substantial operational burden.

EC2-based microservices still bring familiar challenges like infrastructure provisioning overhead, environment management complexity, patching and upkeep, uneven service utilization, and operational friction when many services evolve independently.

In other words, microservices improved the software structure, but did not fully solve the platform-operating problem.

That required the next shift.

Phase 3: Multi-Tenant Serverless Microservices with ECS/Fargate and Lambda

Our next architectural step was toward a more serverless operating model using ECS/Fargate and Lambda as key runtime patterns in a broader AWS-native platform. This shift was not driven by fashion. It was driven by architectural fit.

Once you are building a true multi-tenant fintech platform with domain-driven service boundaries, event-driven choreography, workflow orchestration, NoCode object and process modeling, configurable rules, and variable workload patterns across tenants, serverless starts making deep sense.

Why? Because serverless aligns naturally with the kind of system we wanted to become.

It supports:

  • finer-grained scaling
  • service isolation
  • elastic execution
  • faster release of narrowly scoped capabilities
  • lower infrastructure management overhead
  • better alignment between workload shape and runtime model

For us, serverless was not just about cost. It was about architectural fit.

Lambda became a natural fit for event-driven execution, orchestration steps, and targeted workflow actions.

Fargate gave us a managed container runtime for services that needed containers without the operational baggage of managing servers.

Together, they allowed us to move toward a platform where engineering energy could go upward — toward domain capability and business adaptation — instead of downward into undifferentiated infrastructure effort.

The Real Shift: From Applications to Infrastructure Primitives

The most important part of our journey is not the move from EC2 to serverless by itself.

It is the fact that this shift coincided with a deeper platform rethink. We stopped thinking only in terms of screens, modules, and custom workflows. We began thinking in terms of reusable financial technology infrastructure primitives.

These primitives include domain objects, object repositories, service registries, stage and status models, process orchestration, event-driven choreography, lookup and master data services, bulk operations, document handling, auditability, and tenant-aware platform services.

This is where serverless became more than a runtime decision.

When a platform is built around reusable primitives instead of bespoke application logic, serverless enables a very different operating model: deploy smaller units, evolve independently, respond to events, compose business journeys dynamically, and scale without rebuilding the system every time business change arrives.

That is a very different mindset from traditional enterprise software.

Serverless Beyond APIs: Workload-Shaped Compute for Heavy Financial Processing

One of the more interesting lessons from our platform journey is that serverless was not only useful for APIs, event handlers, and orchestration flows. It also became a powerful model for heavy batch processing.

Financial technology platforms often contain workloads that are computationally intensive, bursty, and highly variable: payout computations, hierarchy rollups, rule-intensive reconciliations, large-scale imports and exports, statement generation, scorecard calculations, and tenant-specific batch jobs.

These are not always good candidates for fixed, permanently provisioned infrastructure. If you size for the largest batch all the time, you overprovision. If you size for the median batch, peak jobs suffer.

So, we evolved a different pattern.

For computationally intensive batch jobs, our platform can spawn ECS Fargate tasks on demand, with the size of those tasks computed dynamically based on the batch size and workload characteristics. In other words, compute is no longer statically assigned. It is shaped to the work itself.

That has several advantages:

  1. Heavy jobs do not force idle infrastructure to sit around waiting.
  2. Compute capacity can match the actual workload envelope.
  3. Rest of the platform remains cleaner and less distorted by batch extremes.
  4. Large multi-tenant processing loads can be handled more elastically.

This is an important part of what serverless means to us. Not merely “no servers to manage,” but elastic compute as a native platform capability.

That distinction matters. Because in a modern fintech platform, compute should adapt to the business workload — not the other way around.

Why This Matters in BFSI

BFSI platforms are not simple CRUD systems. They deal with high-value transactions, regulated processes, complex approval and decision journeys, multi-step payout and accounting flows, frequent business-rule changes, auditability requirements, and variable workload intensity.

In that environment, architecture has to be designed not just for scale, but for ongoing adaptation with control. Serverless helps support that by enabling finer-grained service evolution, event-driven processing, elastic batch execution, lower ops friction, and cleaner separation between steady-state services and burst-heavy workloads.

For a vertical fintech platform, that matters enormously. The market does not reward infrastructure heroics.

It rewards speed of business adaptation with enterprise-grade control. That is what serverless helped unlock for us.

Why NoCode and Serverless Belong Together

One of the most powerful insights from our journey is that NoCode and serverless complement each other extremely well. NoCode, in our context, is not simplistic drag-and-drop tooling.

It is about moving business variability upward: object definitions, workflows, rules, stage/status transitions, service interaction patterns, and domain behavior.

Serverless, meanwhile, helps move infrastructure burden downward: less server management, less provisioning friction, less operational clutter.

So the platform can meet in the middle: more business configurability, less infrastructure drag, more focus on domain capability, faster evolution of client-specific and domain-specific needs.

That combination is powerful.

What We Learned

  1. Architecture must follow business volatility: In financial services, change is not an exception. It is the environment.
  2.  Microservices alone are not enough: You can decompose software and still remain trapped by the old operating model.
  3. Serverless works best when tied to a platform philosophy: On its own, it is a runtime choice. Combined with DDD, NoCode, orchestration, and eventing, it becomes far more powerful.
  4. Elasticity matters most when it becomes workload-aware: Some of the biggest gains come not from always-on scaling, but from compute that can be dynamically shaped to the size and intensity of the actual work.
  5.  The real prize is not infra efficiency alone: The real prize is business agility with control.

The Road Ahead

Our platform journey is still unfolding.

But one thing is now clear to us: the future of financial technology platforms will not be built as giant stitched-together application suites. It will be built as composable, domain-aware, configurable infrastructure.

That is the promise behind our RTB journey. From single-tenant monoliths to multi-tenant microservices to serverless, NoCode financial technology infrastructure-as-a-service this has been more than a technology migration.

It has been a change in what we believe a fintech platform should be.

Table of Content

You may also like