Unified Payments Data Read at Airbnb

How we redesigned payments data read flow to optimize client integrations, while achieving up to 150x performance gains.

Airbnb logo
Airbnb
•
Alican GÖKSEL
•12 min read•advanced•
--
•View Original
AmbassadorElasticsearchJavaKong

Overview

The article discusses Airbnb's transition from a monolithic architecture to a service-oriented architecture (SOA) for its payments system, highlighting the challenges faced and the development of a unified payments data read layer. This new architecture aims to simplify client integrations, enhance performance, and improve reliability across various payment-related functionalities.

What You'll Learn

1

How to unify payment data read entry points using a data-oriented service mesh

2

Why denormalization can improve query performance in complex systems

3

How to implement higher-level domain entities to simplify API interactions

Key Questions Answered

What challenges did Airbnb face during the migration to SOA?
Airbnb encountered several challenges during its migration to a service-oriented architecture, including the need for clients to understand the payments domain, the complexity of changing multiple APIs simultaneously, and the technical quality of read flows not meeting performance expectations. These issues impacted time to market and the overall user experience.
How did Airbnb improve the performance of its payments system?
Airbnb improved the performance of its payments system by implementing a unified data read layer that consolidated multiple services into a single entry point. This architecture allowed for denormalization of data, resulting in up to 150x latency improvements and increasing reliability from approximately 96% to over 99.9%.
What is the purpose of the read-optimized store framework?
The read-optimized store framework is designed to materialize denormalized data efficiently, allowing for near real-time data access and reducing the complexity of queries. This framework supports both online and offline data ingestion, significantly improving performance and reliability for payment-related queries.

Key Statistics & Figures

Latency improvement
150x
Achieved during the migration of the Transaction History page to the new unified data read architecture.
Reliability increase
from ~96% to 99.9+%
This improvement was noted after implementing the new payments read flow.

Technologies & Tools

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

Database
Elasticsearch
Used for storing denormalized payment data to improve query performance.
Service Mesh
Viaduct
Airbnb’s data-oriented service mesh that facilitates unified access to payment data.

Key Actionable Insights

1
Implementing a unified data read layer can significantly simplify client interactions with complex systems.
By reducing the number of APIs clients need to interact with, organizations can streamline development processes and enhance user experiences.
2
Denormalization of data can lead to substantial performance gains in data retrieval.
This approach minimizes the need for complex joins during query time, thus improving response times and reducing server load.
3
Creating higher-level domain entities can help shield clients from internal complexities.
This strategy allows for easier integration and adaptation to changes in the underlying architecture without requiring client-side modifications.

Common Pitfalls

1
Failing to account for the complexity of multiple APIs can lead to integration challenges.
When clients need to interact with numerous services, it can slow down development and complicate the onboarding process.
2
Neglecting performance optimization during data retrieval can result in slow user experiences.
Without proper denormalization and efficient data access patterns, applications may suffer from high latency and poor reliability.