Rebuilding Payment Orchestration at Airbnb

How we maintained reliable money movement while migrating Airbnb’s payment orchestration system from the legacy monolithic application to a…

Bryon Ross
10 min readadvanced
--
View Original

Overview

The article discusses Airbnb's migration from a monolithic Ruby on Rails application to a service-oriented architecture (SOA) for their payment orchestration system. It highlights the challenges faced, the redesign strategies implemented, and the importance of maintaining consistency and extensibility in the new system.

What You'll Learn

1

How to implement idempotent orchestration in distributed payment systems

2

Why data immutability is crucial for payment systems

3

How to design a product-agnostic payment platform

Prerequisites & Requirements

  • Understanding of service-oriented architecture (SOA) principles
  • Familiarity with distributed systems concepts

Key Questions Answered

What are the key features of Airbnb's new payment orchestration system?
The new payment orchestration system focuses on idempotency, platformization, and data immutability. It allows for reliable money movement, supports various products, and maintains eventual consistency through a directed acyclic graph (DAG) of idempotent steps, enhancing the reliability of payment processing.
How did Airbnb manage the migration to a service-oriented architecture?
Airbnb's migration was phased into four major parts: Pricing, Payouts, Bookings, and Data Migration. This approach allowed for thorough testing and validation of each phase, ensuring that new features could be integrated without disrupting existing services.
Why is data immutability important in payment systems?
Data immutability simplifies understanding, auditing, and reconciling transactions. By using persistent events and versioning, the payment orchestration system can maintain a complete history of money movement, making it easier to track changes and ensure consistency.
What challenges did Airbnb face during the migration process?
Maintaining two parallel systems during the migration created overhead and slowed down feature iteration. Teams had to decide whether to implement changes in one or both systems, often leading to duplicated efforts and necessitating clear communication with stakeholders.

Key Statistics & Figures

Consistency rate
99.999%
This high level of consistency was achieved through the use of an idempotency framework in the new payment orchestration system.

Technologies & Tools

Some links below are affiliate links. We may earn a commission if you make a purchase.

Key Actionable Insights

1
Implementing idempotent orchestration can significantly enhance the reliability of payment processing in distributed systems.
By structuring workflows around idempotent steps, teams can ensure that payment transactions are processed consistently, reducing the risk of errors and improving user trust.
2
Designing a product-agnostic payment platform can streamline integration for new features and products.
This approach minimizes engineering effort and accelerates time to market, allowing teams to focus on innovation rather than reworking existing payment logic.
3
Prioritize data immutability in payment systems to simplify auditing and reconciliation.
Immutable data structures provide a clear historical record of transactions, making it easier to track changes and resolve discrepancies.

Common Pitfalls

1
Failing to communicate effectively with stakeholders during a migration can lead to misalignment and project delays.
Clear communication is essential to ensure that all teams are aware of timelines and constraints, which helps avoid unnecessary slowdowns in product development.

Related Concepts

Service-oriented Architecture (soa)
Idempotency In Distributed Systems
Data Immutability
Event-driven Architecture