Brass — Events, Indexing & Backfill

Overview

During my internship at Viator (Tripadvisor) in London, I worked on Brass, our event-driven bookings index. Brass ensures that whenever a booking changes, suppliers have access to a searchable, real-time summary of the latest state of that booking. My work involved designing, implementing, and extending the end-to-end service that listens to booking events, transforms the data, and makes it instantly searchable.

The Challenge

Viator processes millions of bookings globally, and suppliers rely on accurate, timely updates. Before Brass, the visibility of booking updates was limited and not always synchronized. We needed:

• A real-time pipeline to capture booking changes.

• A searchable index that suppliers could query for up-to-date information.

• A backfill mechanism to reprocess historical data and ensure older bookings were included in the index.

My Contribution

I built and extended the Brass service to support both real-time indexing and historical backfills:

1. Real-Time Event Subscription

• Developed an event subscriber using Spring Boot that listens to Kafka booking events in real time.

• Subscribed to streams such as BookingUpdateEvent and BookingReportEvent.

• Logged, validated, and processed incoming events to guarantee integrity.

2. Data Retrieval via OpenFeign

• Implemented an OpenFeign client to fetch Booking Summaries directly from Viator’s booking APIs.

• Ensured smooth handling of failures and retries when upstream systems were under load.

• Used the booking reference or itinerary item ID as input, depending on the event type.

3. Mapping & Transformation

• Built a BookingSummaryMapper service that transforms raw summaries into a structured Booking document.

• Normalized key attributes such as booking ID, itinerary details, timestamps, and traveler information.

• Guaranteed schema consistency for indexing in OpenSearch.

4. OpenSearch Indexing

• Designed the indexing logic so that each processed booking summary is persisted into OpenSearch.

• Ensured updates overwrite existing records, keeping supplier-facing search always in sync.

• Optimized for query speed and scalability.

5. Backfill Pipeline

• Created a backfill subscription that replays historical booking events.

• Routed old events through the same pipeline (subscriber → Feign client → mapper → OpenSearch).

• This ensured that even bookings created before Brass was deployed were now searchable.

Result & Impact

• Delivered a real-time, event-driven booking index that keeps supplier-facing data accurate and always up to date.

• Enabled instant search across millions of bookings, reducing delays and improving supplier trust.

• Provided a backfill mechanism that ensured no data gaps, reinforcing data reliability.

• Overall, Brass became a scalable and resilient service, powering critical supplier-facing functionality at Viator.

Architecture Flow

Live path: Event → Subscriber → OpenFeign client → Mapper → OpenSearch index

Backfill path: Backfill source → same pipeline → OpenSearch index

This project was one of the most impactful experiences of my internship, as it combined distributed systems, real-time event processing, API integration, and search indexing into one production-grade pipeline that suppliers rely on daily.