To decompose or not to decompose, that is the question

To decompose or not to decompose, that is the question. This Shakespearean dilemma aptly captures the challenge faced by payment architects today. A good deal of core payment switching and authorization technology is built on monolithic legacy application stacks. Armed with a quest to modernize, a natural tendency is to hit the legacy application with a decomposition hammer and turn the core payment application into an array of microservices. But is this transformation always the optimal solution, and how granular should the decomposition of services be to truly add value without introducing unnecessary complexity?

The Challenges of Microservices in Payment Processing

Payment processing is a complex enterprise requiring strong consistency, low latency, and robust compliance. Moreover, payment processing lends itself well to a linear processing model due to its all-or-nothing approach, i.e., it’s usually the case that all functions such as message deserialization, parsing, validation, and security functions need to be successful for the payment to be successful. A linear, fail-fast model shines brightly in this environment.

Microservices, while promising flexibility, can sometimes be like adding extra gears to a machine—introducing complexity, potential delays, and new security challenges. Here are some of the key challenges:

• Strong Consistency and ACID Transactions: Payment processing platforms demand extremely high levels of consistency and data integrity. Traditionally, these systems rely on the ACID (Atomicity, Consistency, Isolation, Durability) properties to ensure that financial transactions either fully complete or rollback, preserving data accuracy and transaction integrity. In a microservices environment, distributing this data across multiple services and data stores, makes strict ACID compliance more complex.
• High Throughput and Low Latency Demands: Payment platforms typically process large volumes of transactions in real-time, and even minor delays can negatively affect user experience and risk financial losses. Distributing the workflow across multiple microservices can lead to network hops, serialization delays, and the overhead of service coordination.
• Regulatory and Compliance Complexities: Financial transactions are highly regulated, governed by a mix of local and international rules such as PCI DSS, GDPR, and various banking compliance guidelines. Keeping audit trails, safeguarding data privacy, and ensuring encryption are simpler when everything is under one roof.  A microservice-based architecture extends these challenges because each service must individually comply with security and audit requirements.
• Operational Overhead and Complexity: Running a microservices ecosystem in production is like juggling multiple balls in the air—each layer of deployment, versioning, monitoring, and scaling adds to the complexity.

The Case for a Hybrid Approach

While the allure of microservices can be strong, it's essential to remember the adage: "When holding a hammer, everything looks like a nail." Decomposition is a powerful tool, but overdoing it potentially leads to unnecessary complexity.

There is a continuum between pure monolithic and highly decomposed microservices architectures. The benefits of these architectural styles are not exclusively found at the extreme ends of the spectrum. A modern payment platform must find a sweet spot on the decomposition curve that balances simplicity and performance with scalability and availability.

By adopting a hybrid approach, combining microservices for peripheral functions such as reporting, analytics, and notifications, whilst maintaining a less decomposed, albeit distributed core transaction engine, organizations can achieve the best of both worlds.