How Booking com designed and scaled their highly available and performant User Review System



8791 views Backend System Design



The review system for Booking is one critical service as it drives business and hence making it highly available becomes extremely crucial.

Here’s a thread about building a highly available system and the architecture of Booking’s Review Service 👇‍

Importance

Review shown on Booking.com are authentic and it helps people make a decision and thus bring in revenue.

The review system is also a high-throughput system as people can land on it from Search Engines or internal navigation.

Review API Service

The core Review Service will be a simple REST-based API that exposes endpoints to create, read, update, and delete reviews.

Review Service of Booking handles 10,000 requests per second at peak with p99 of 50ms.

Given that the latncy requirement is too stringent, Booking serves most of the review from a centralized remote Cache and has done a bunch of optimizations on the Database through materialized views.

Configuring storage

Booking.com has 250 million reviews and given the amount of info a review holds, they store these reviews in a shared datastore.

Given Booking needs storage to be highly available, they configured each database to have multiple replicas and that too across regions to tolerate regional outages.

Auto-scaling Storage

Given that the traffic for a travel business surges during the holiday season, the database needs to be scaled up to handle the load.

But keeping the database scaled up throughout the year without much load is very inefficient and hence Booking.com required some so of storage autoscaling.

Scaling up and down a sharded database requires us to add and remove nodes; but doing this naively requires the data to be re-partitioned.

To keep the movement to a bare minimum during scaling, Booking.com chose Consistent Hashing for determining data ownership.

Architecture

  1. Review Service is a simple REST service
  2. Centralised cache and materialized views for quicker response
  3. Database is sharded to handle larger loads
  4. Data ownership is determined by Consistent Hashing
  5. Database is replicated across within and across regions for HA

Arpit Bhayani

Arpit's Newsletter

CS newsletter for the curious engineers

❤️ by 38000+ readers

If you like what you read subscribe you can always subscribe to my newsletter and get the post delivered straight to your inbox. I write essays on various engineering topics and share it through my weekly newsletter.




Other essays that you might like



Be a better engineer

A set of courses designed to make you a better engineer and excel at your career; no-fluff, pure engineering.


Paid Courses

System Design for Beginners

A masterclass that helps early engineers and product managers become great at designing scalable systems.

300+ learners

Details →

System Design Masterclass

A masterclass that helps you become great at designing scalable, fault-tolerant, and highly available systems.

1000+ learners

Details →

Redis Internals

Learn internals of Redis by re-implementing some of the core features in Golang.

98+ learners

Details →

Free Courses

Designing Microservices

A free playlist to help you understand Microservices and their high-level patterns in depth.

823+ learners

Details →

GitHub Outage Dissections

A free playlist to help you learn core engineering from outages that happened at GitHub.

651+ learners

Details →

Hash Table Internals

A free playlist to help you understand the internal workings and construction of Hash Tables.

1027+ learners

Details →

BitTorrent Internals

A free playlist to help you understand the algorithms and strategies that power P2P networks and BitTorrent.

692+ learners

Details →