You are viewing content from a past/completed QCon -

Presentation: CRDTs in Production

Track: Production Readiness: Building Resilient Systems

Location: Ballroom A

Duration: 2:55pm - 3:45pm

Day of week: Wednesday

Slides: Download Slides

Level: Intermediate - Advanced

Persona: Backend Developer, Developer

This presentation is now available to view on

Watch video with transcript

What You’ll Learn

  1. Hear how PayPal developed a distributed system dealing with consistency issues.

  2. Find out what scenarios eventual consistency works for.

  3. Learn that eventual consistency is doable and why it matters.


In search of scalability and availability improvements, many companies adopt eventual consistency as the consistency model underlying their stateful systems and persistent data stores. At the same time, software designers are focused on creating resilient systems ready to work in production with minimal complexity. Dmitry will share lessons learned in developing a distributed system based on an eventually consistent data store. The final solution utilizes conflict-free, replicated data types with causality tracking to achieve strong eventual consistency for critical data in multi-master, multi-datacenter DB (Aerospike) deployments.


What's the focus of the work that you're doing today?


This project on CRDT was my first project at PayPal and I was part of PD platform team. This is a team on top of infrastructure which provides services which will be used by product development engineers. Our platform allows us to drive the product development aligned with existing infrastructure and at the same time, we need to be efficient in throughput and consistency. We designed this CRDT solution specifically for our situation for our partners and for our infrastructure current state. There is also a requirement how many dependencies we can afford. For example, why CRDT was a very good fit because we say that we don't know the configuration of the cluster. We don't know how many data centers they have. This immediately removed the possibility to use consensus protocols because consensus is based on n divided by 2 plus 1 nodes and we don't have this capability on the infrastructure side. From the box it means that we need to implement it but we don't know about infrastructure. That's why we tried to build a reliable solution on not very reliable components.


What was the specific use case that you were solving?


We are talking about compliance statuses. This is something like whether you're verified, whether you can or cannot transact.


Who is the core audience you're talking to?


I'm talking to product architects who build product solutions like services. They might live in cloud or on premise infrastructure, but they do not always have enough control, how many databases, how databases are shared, how the network is organized. This is the reality that we face today in most companies. You just have solutions. And if there is a spike on other databases we say 'We provide consistency for this and that, but for anything else, we do not provide it', and you need to have something reliable.


So the reason why CRDT has made the most sense for PayPal is because you didn't have the exact number of the quorum because the infrastructure could change?


Exactly. And we also need remote deployment. This means that nodes should be able to work in isolation for some period of time. And if the majority of the cluster is not accessible for this node we should still be able to handle requests.


Why is this talk in the production readiness track?


Because as product developers we want to be able to provide high quality of services, high availability regardless of what's going on in infrastructure. We want to achieve maximum efficiency with the components that we have today, and with the anticipation of what these components behavior might be.


Is this an advanced or intermediate talk?


I would say this is an advanced talk.


What do you want someone to walk away from this talk with?


First of all, I want someone to walk away knowing that eventual consistency is feasible. Recently I was in a FoundationDB talk, and somebody said that eventual consistency equals no consistency. I disagree with that. This is not easy. This has to be designed well and to think about the access patterns. It is not generic. It is very specific for some particular case. You need to have assessment of what the root cause of your concurrency issue is. But it is feasible and it allows you to avoid the issues resulting from network latency because I think that in the current scale and pace of interaction between people and technology synchronized solutions are very limited.

Speaker: Dmitry Martyanov

Software Engineer @PayPal

Software engineer at PayPal working with a focus on distributed systems and resilient architectures.

Find Dmitry Martyanov at

Last Year's Tracks

  • Monday, 16 November

  • Clientside: From WASM to Browser Applications

    Dive into some of the technologies that can be leveraged to ultimately deliver a more impactful interaction between the user and client.

  • Languages of Infra

    More than just Infrastructure as a Service, today we have libraries, languages, and platforms that help us define our infra. Languages of Infra explore languages and libraries being used today to build modern cloud native architectures.

  • Mechanical Sympathy: The Software/Hardware Divide

    Understanding the Hardware Makes You a Better Developer

  • Paths to Production: Deployment Pipelines as a Competitive Advantage

    Deployment pipelines allow us to push to production at ever increasing volume. Paths to production looks at how some of software's most well known shops continuous deliver code.

  • Java, The Platform

    Mobile, Micro, Modular: The platform continues to evolve and change. Discover how the platform continues to drive us forward.

  • Security for Engineers

    How to build secure, yet usable, systems from the engineer's perspective.

  • Tuesday, 17 November

  • Modern Data Engineering

    The innovations necessary to build towards a fully automated decentralized data warehouse.

  • Machine Learning for the Software Engineer

    AI and machine learning are more approachable than ever. Discover how ML, deep learning, and other modern approaches are being used in practice by Software Engineers.

  • Inclusion & Diversity in Tech

    The road map to an inclusive and diverse tech organization. *Diversity & Inclusion defined as the inclusion of all individuals in an within tech, regardless of gender, religion, ethnicity, race, age, sexual orientation, and physical or mental fitness.

  • Architectures You've Always Wondered About

    How do they do it? In QCon's marquee Architectures track, we learn what it takes to operate at large scale from well-known names in our industry. You will take away hard-earned architectural lessons on scalability, reliability, throughput, and performance.

  • Architecting for Confidence: Building Resilient Systems

    Your system will fail. Build systems with the confidence to know when they do and you won’t.

  • Remotely Productive: Remote Teams & Software

    More and more companies are moving to remote work. How do you build, work on, and lead teams remotely?

  • Wednesday, 18 November

  • Operating Microservices

    Building and operating distributed systems is hard, and microservices are no different. Learn strategies for not just building a service but operating them at scale.

  • Distributed Systems for Developers

    Computer science in practice. An applied track that fuses together the human side of computer science with the technical choices that are made along the way

  • The Future of APIs

    Web-based API continue to evolve. The track provides the what, how, and why of future APIs, including GraphQL, Backend for Frontend, gRPC, & ReST

  • Resurgence of Functional Programming

    What was once a paradigm shift in how we thought of programming languages is now main stream in nearly all modern languages. Hear how software shops are infusing concepts like pure functions and immutablity into their architectures and design choices.

  • Social Responsibility: Implications of Building Modern Software

    Software has an ever increasing impact on individuals and society. Understanding these implications helps build software that works for all users

  • Non-Technical Skills for Technical Folks

    To be an effective engineer, requires more than great coding skills. Learn the subtle arts of the tech lead, including empathy, communication, and organization.