2

I have question regarding system design. Lets say I want to design a Flight booking system ( such as American Airlines). So, consistency when booking a ticket is very important. This booking system is also used across the world. A high level view of the system would look some thing like below (lets say servers are in NYC-New York).

distributed RDBMS

Consider that people from Germany, USA , Canada all uses this system .

In this case would every user ( booking the same flight AE-101 on a given day) across the world would be hitting the same load balancer and then same DB ( present in NYC).

OR

Do we maintain the distributed copy of DB across multiple regions so that clients from Europe hit a different Load Balancer and clients from Canada hit a different one. If that's the case how do we maintain consistency over geographically separated master DB. Does the write server waits until all the replicas of DB present across the world gets updated?

3
  • 2
    Considering the consistent overbooking practice of airlines, consistency might not be as important as you think. Aug 31, 2020 at 7:32
  • 1
    @StackManaged If you are considering to use the second approach then you are entering in a realm of multi leader replication. Detailed description of this topic can be found in this book: Designing Data-Intensive Applications. The Big Ideas Behind Reliable, Scalable and Maintainable Systems. TL;DR: by introducing multiple nodes which can accept write requests then you have to deal with complex merge conflict resolutions. Aug 31, 2020 at 13:34
  • 1
    Thanks @PeterCsala , the link you shared is amazing. It gives amazing insight . Sep 1, 2020 at 3:32

1 Answer 1

6

This depends on the consistency guarantees you want to fulfil. There are many different consistency models, but some are easier to achieve than others.

Normally, the use of read replicas is consistent in the sense that the read replica sees an older but consistent state of the primary database. So transactions are either successful or they aren't applied at all, all constraints are still satisfied. Different read replicas may represent snapshots at different points in time. Writes must be executed on the primary node. Some databases may wait to confirm a transaction until all replicas are up to date, but of course that slows down writes a lot.

This model works fairly well if you have way more reads than writes. But it can violate other consistency models. If a user observes the state in replica A and then in replica B, they might see different states. When they apply a modification on the primary and then observe the state of the replica, the replica might not yet know about that state.

If you want to have multiple database nodes to handle writes, then things get very tricky. This is not impossible, just difficult to do efficiently. At best, you can simply shard your booking database e.g. by flight number, so that for every booking there is only a single authoritative node. Google's Cloud Spanner uses sharding in combination with distributed locks and consensus protocols such as Paxos with the result that most writes can be executed on nearby nodes, without acquiring locks on all nodes.

But all of that is too complicated:

  • a single database server to handle writes, with reasonable hardware and a reasonable schema design, is likely able to handle the entire write load. Bookings involve money so are somewhat rare, compared to truly web-scale problems like Twitter or analytics.

  • there's no problem by keeping your database in a single geography. Sucks for users for Australia due to increased latencies, but is much more efficient than trying to maintain consistency in a globally distributed database. If you do want to go down the route of globally distributed writes, definitely use an existing cloud service like Cloud Spanner.

  • the flight booking industry doesn't offer such strong consistency at the business level, so trying to guarantee strong consistency on the database level is a bit pointless. Airlines routinely overcommit bookings in order to ensure a full plane despite no-shows. Bookings are sold through a complex network of affiliates and partners that makes it nigh impossible to get a consistent view of bookings – this is instead resolved at check-in time.

    This doesn't mean that inconsistency is OK, but that the technical solution must be aligned with the business processes.

1
  • Thanks @amon for taking your time to explain it. Sep 1, 2020 at 3:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.