Fiserv Bets on Distributed SQL for Scale
Fiserv is using distributed SQL to future-proof its data platforms for enterprise-scale finance. In a case study shared by YugabyteDB, the architecture was shown to achieve sub-200ms scaling for mission-critical systems. This highlights a key trend: moving away from traditional monolithic databases to distributed systems that offer both resilience and performance for high-throughput financial workloads.
Before migrating, Fiserv's legacy architecture, which included Oracle, SQL Server, and Cassandra, created performance bottlenecks and high costs. The company processes up to 25,000 financial transactions per second during peak loads, and its previous attempts at scale involved manual application-layer sharding, which proved to be brittle, complex, and difficult to balance. The new globally distributed platform, specifically for keying and linking, processes 300 million records daily with sub-20ms API latency. This system was built to meet stringent technical requirements, including the ability to deliver over 19,000 IOPS per node and support thousands of concurrent Spark writers using atomic Raft writes for data consistency. According to Dmitri Farafonov, VP and Fellow Architect at Fiserv, their high-availability strategy mandates triple replication within a single region for local quorum. That entire replica set is then replicated to a second region, meaning a minimum of six copies of every record exists to ensure zero downtime and data integrity across failures. The move addresses the limitations of prior NoSQL adoption. Jay Duraisamy, Fiserv's SVP of Technology for Data and Analytics, views distributed SQL as the next evolution of NoSQL architecture, merging the scalability benefits with the full ACID compliance and PostgreSQL compatibility required for mission-critical financial ledgers. API compatibility with both PostgreSQL and Cassandra was a key selection criterion. This dual-grammar support allows development teams to accelerate migration and leverage existing skill sets without being locked into a single access pattern, accommodating diverse workload types on a unified platform. Fiserv's selection process is intentionally rigorous due to strict security and regulatory demands. The company requires extensive auditing capabilities for every single database interaction, from both application and administrative accounts, a standard that many newer technologies cannot immediately meet for prime-time financial service applications.
