Sitemap
Next at Chase

We’re telling the story of how we’re becoming one of the industry’s most exciting places to build a career in tech, product management, data & analytics and design.

Middleware Re-engineered: An Effective Approach to Decouple a Complex Monolith

--

By: Aditya Lodha, Managing Director of Software Engineering, Chase

As one of the largest banks in the United States, Chase’s digital banking platform serves 84 million consumers and seven million small businesses, with a total of approximately 67 million active digital users. At peak hours, our systems process tens of thousands of transactions per second, ensuring seamless banking experiences. Behind the scenes, this scale demands a robust middleware platform that efficiently manages data orchestration, performance optimization, and service reliability.

Middleware architectures play a pivotal role in orchestrating customers’ digital experiences. The platform’s components underpin numerous back-end banking and communication processes, including payment platforms, account servicing platforms, customer alerts and communications, and customer information management.

As the banking landscape evolved over time, our middleware expanded to include a wide range of business functionalities and organically grew into a huge monolithic platform. Rather than a complete teardown, we evolved our architecture to be more efficient, scalable and resilient — all while keeping the system running at scale.

At its core, the challenge and intrigue of this initiative was that we were going to upgrade the engine while the aircraft remained airborne, ensuring continuous operation without disruption.

Our success helped the team to take on cloud migration with ease and allowed for the decommissioning of the legacy monolithic infrastructure.

Here’s how we tackled this complex challenge — at scale — and solved for now and for the future of our modernization journey.

Legacy Middleware: Navigating Complexity Challenges

Middleware platforms serve as essential intermediaries between the presentation layer and multiple Systems of Record (SORs). They adeptly manage large volumes of data, ensuring swift response times while maintaining the platform’s scalability and resilience. Additionally, they apply business logic with precision, enhancing the overall efficiency and reliability of the system.

Over the course of time, our legacy middleware had become a bottleneck — slowing down product delivery, increasing operational complexity, limiting scalability, and with time, introducing several challenges beyond its structure:

Intricate Dependency Management: Aggregating, transforming and enriching data from multiple SORs in real time required complex dependencies.

Dynamic Scalability Constraints: The monolith faced challenges with dynamic scaling, particularly during peak transaction surges, as it couldn’t independently scale specific functionalities based on demand.

Constraints in Operational Adaptability: The tightly coupled components made debugging, monitoring, testing, and introducing new capabilities increasingly difficult and time consuming.

Compliance and Security Demands: Compliance and security are of paramount importance due to the sensitive nature of financial data and the regulations that govern its handling. Monolithic architectures, while initially simpler to develop and deploy, often struggle to meet the evolving demands of compliance and security.

Any platform disruptions could result in financial losses, harm the institution’s reputation by eroding customer trust, and incur regulatory penalties for non-compliance, highlighting the necessity of ensuring platform stability and reliability.

This decision to transition away from a legacy monolithic system was driven by the need to address these several critical challenges mentioned above. The existing architecture’s complexity and outdated infrastructure impeded the adoption of modern solutions, affecting product delivery timelines and increasing operational costs. Such factors underscored the necessity for a more agile and scalable architecture to enhance operational efficiency and support future growth.

We needed a modernization strategy to improve system performance, enhance development agility and strengthen reliability, while minimizing risk. By evolving our architecture rather than overhauling it, we aimed for a more responsive, stable and scalable system.

Image depicts the concerns with all monolithic architecture, with each concern mentioned in the bubble as a ‘star’ diagram. The concerns depicted are: Inability in independent feature development; Higher cost to change; Inability to scale dynamically; Challenge in remediating software risks; Longer time to market; and Blast radius impacting platform stability.

Options to Address Our Challenges

To address our challenges, we evaluated two architectural options: Functional Segmented Applications and Microservices. This evaluation considered factors such as scalability, complexity, team structure, and operational overhead.

A Functional Segmented Application is a service container that encompasses related functionalities within a single deployment.­

While it is smaller than a traditional monolith, it does not decompose everything into independent services. In contrast, a microservices architecture breaks down an application into small, independently deployable services that communicate via APIs. Each approach offers distinct advantages and trade-offs, and our decision was guided by the need to balance these factors effectively.

Why We Chose the Scalable Functional Aligned Services (SFAS) Model Over Pure Microservices

Microservice architecture is a widely adopted approach to modernization, but given our scale, moving directly to microservices would introduce new challenges:

Data Consistency and Orchestration Overhead: Microservices require distributed data management, increasing latency and synchronization complexities.

Network Congestion & Integration Overheads: More inter-service communication could result in performance degradation.

Operational Complexity: Managing thousands of microservices in a highly regulated environment is a resource overhead.

Cost: Implementing and maintaining a microservices architecture can result in higher infrastructure and operational expenses due to the increased complexity of managing numerous independent services.

Also, owing to complex integration overhead, network congestion, and increased dependency and incompatibilities, we refrained from opting for a purely microservice architecture. Instead, we opted for what we now refer to as ‘Scalable Functional Aligned Services,’ or simply SFAS, where we segregated the Monolith yet maintained functional and business integrity. Decomposing the monolithic middleware platform into functional service groups led to an optimized codebase that increased product autonomy, enabling a quicker feature rollout. Keeping these principles in mind, we aimed to balance complexity, scalability and cost in our architectural decisions.

Illustrates how traffic from web and mobile channels interacts with the middleware application layer through the presentation layer. In the ‘MONOLITH’ state, a single large unit handles all the traffic. In contrast, the ‘DECOMPOSED’ state features multiple distinct product service groups, each dedicated to handling specific service traffic.

Platform Readiness: How We Decomposed for an Independent and Scalable Architecture

Following due diligence steps, we adopted the below approach to get to a Scalable Functional Aligned Services Model state:

Thorough Analysis: Every service in the monolith architecture was scrutinized for their ingress-egress volumes. The services were bucketed into logical grouping to split the monolith into Scalable Functional Aligned Services (SFAS).

Infrastructural Shift: To address current needs, we leveraged cloud infrastructure for better compute, throughput and scalability.

Channel Agnostic Routing: We implemented a reverse proxy to distribute traffic intelligently agnostic to channel.

Caching Re-engineered: We revamped our caching strategy from sticky in-memory caching to distributed caching using a distributed data management infrastructure. This transformed the Scalable Functional Aligned Services Architecture into a stateless system, providing a more robust, scalable and reliable caching solution.

Testing Strategy: Laying the Foundation for Engine Readiness of the New Platform

To ensure a smooth and successful takeoff we kept in place certain checks and practices, covering exhaustive test-scenarios:

API Comparison for Payload and Service Response: We conducted a detailed comparison of API payloads to be consistent and response times to have positive deviations.

Behavior Driven Development: An agile software development methodology was adopted across all applications to execute product-aligned behavioral tests on all comprehensive profile combinations.

End to End Testing: All customer journeys were simulated to facilitate consistent and seamless user experiences across the new platform.

Performance/Endurance Testing: To uphold non-functional integrity such as stability, scalability and responsiveness with varying loads, we performed exhaustive endurance and capacity tests.

Failure Mode and Effects Analysis: Points of failure were secured by simulating in a controlled environment and implementing fault tolerant capabilities.

Production Validation: We adopted a fail-fast approach with an initial pilot rollout and validation followed by staggered releases, safeguarding stability and integrity to the platform.

Mixed-mode Rollout Strategy

To transition from monolith standalone servers to Scalable Functional Aligned Services architecture, we adopted a mixed-mode technique for traffic routing facilitated by reverse-proxy.

The incoming traffic was incrementally diverted from legacy monolith to the modern platform. Eventually both legacy and new servers were operational, allowing us to keep a check on the blast radius, while securing a flawless service to customers.

Depicts flow “Requests,” i.e. the service requests landing on High Availability Proxy (HAP) and getting split between Legacy Monolith and Multiple Scalable Functional Aligned Services (Private Cloud). The three instances of the same flow differ in the amount of traffic diverted amongst the two, figures of which are mentioned on the arrows. The traffic decrements on Legacy Monolith side and rises incrementally from 10% traffic to 90% traffic on Multiple Scalable Functional Aligned Services side.

Strategic Outcomes and Key Insights

At Chase, we successfully modernized a critical banking infrastructure at scale increasing the reliability, security, and thereby improving customer experience. Our approach demonstrated how a strategic evolution, rather than a disruptive overhaul, can be leveraged to modernize into a scalable and reliable architecture. By the end of Q1 2024, SFAS were fully operational in private cloud infrastructure which resulted in:

Decoupled Releases: Independent service components allowed teams to develop and deploy features without affecting the entire system.

Improved Developer Productivity: This modular architecture enhanced the debugging-capabilities, streamlined development workflows, and improved overall efficiency.

Faster Product Lifecycle: Improved Time to Market, allowing us to respond to customer needs more rapidly.

Quantifiable improvements:
· API Response time improved by 20%.

· Code coverage increased from 15% to 80%, ensuring better test reliability.

· Fail-change rate dropped below the standard firmwide threshold of 0.27%, increasing system stability.

Scalability & Resilience: The new platform was designed to handle high traffic volumes efficiently, ensuring uninterrupted service availability.

Reduced Production Incidents: By adopting a Scalable Functional Aligned Services model approach, we achieved a substantial 90% decrease in production incidents, enhancing system reliability and customer satisfaction.

This transformation not only optimized our operations but also set the foundation for a seamless cloud migration, decommissioning legacy infrastructure, and unlocking new digital capabilities.

Takeaways From Our Modernization Experience

For large enterprises dealing with legacy systems that run at massive scale, modernization is often an overwhelming challenge. A complete shift to microservice based architecture is not always the best answer. Instead, a SFAS model approach offers a structured way to balance modularity, operational efficiency and business continuity.

Our journey showcases this alternative modernization approach for large enterprises managing legacy middleware, can be referenced as a best-practice and a precedent model by the industry. Key takeaways include:

1. Balance Between Microservices and Monolith: Selecting the appropriate architectural approach is essential for driving modernization without compromising cost efficiency. While adopting a full microservices architecture might not always be the optimal solution, opting for the Scalable Functional Aligned Services model can offer a structured and scalable alternative that balances the benefits of both approaches.

2. Functionally-aligned Service Model: Building Scalable Functional Aligned Services that are functionally aligned with the product model ensures modularity, maintainability and streamlined scalability while retaining operational efficiency.

3. Incremental Transformation Works: Implementing an incremental transformation strategy by strategically decomposing systems can minimize risks and enhance agility, allowing for smoother transitions and adaptations.

4. Invest in Cloud and Distributed Systems: Investing in cloud infrastructure and distributed systems, such as distributed caching, can greatly enhance both performance and scalability, making them essential components for modern applications.

5. Resiliency Testing and Rollouts Are Crucial: Conducting thorough resiliency testing and implementing strategic rollouts are vital for maintaining system stability. By adopting a fail-fast approach and managing traffic migration at the Scalable Functional Aligned Services level, disruptions can be minimized, ensuring effective and reliable operations.

This transformative journey towards functionally aligned products was a strategic leap that fortified not only a technical advancement in streamlining deployment processes but paved a way for achieving market milestones with elevated user experiences.

This approach resulted in a pragmatic and structured transformation model, ensuring minimal disruption while maximizing modernization benefits.

Bhavanish Sardessai, Director of Software Engineering, Parth Vineel Garg, Software Engineer II, and Tanishq Deshpande, Software Engineer contributed to this article.

Like what you’re reading? Check out all our opportunities in tech here.

JPMorgan Chase is an Equal Opportunity Employer, including Disability/Veterans

For Informational/Educational Purposes Only: The opinions expressed in this article may differ from other employees and departments of JPMorgan Chase & Co. Opinions and strategies described may not be appropriate for everyone and are not intended as specific advice/recommendation for any individual. You should carefully consider your needs and objectives before making any decisions and consult the appropriate professional(s). Outlooks and past performance are not guarantees of future results.

Any mentions of third-party trademarks, brand names, products and services are for referential purposes only and any mention thereof is not meant to imply any sponsorship, endorsement, or affiliation.

--

--

Next at Chase
Next at Chase

Published in Next at Chase

We’re telling the story of how we’re becoming one of the industry’s most exciting places to build a career in tech, product management, data & analytics and design.

Next at Chase
Next at Chase

Written by Next at Chase

A blog about technology, product, design, data and analytics, and what it takes to build a career at one of banking's most innovative organizations.