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.
