What happens when read performance is needed on many more counters, such as a fees due one? You can make the write transaction fatter by keeping the multiple denormalized tables updated, but at some point the overhead is going to be overbearing. Also, the counter or view needed of the data might have a business domain that is distinct from the one in which the event originally happened. Thus, trying to update all views might lead to a breach of the separation of concerns principle.

An alternative pattern to handle this situation is event sourcing and materialized views.

In event sourcing, the service doing the business transaction emits an event describing the change. In the case of the preceding Booking example, it can be a Booking Event. This event is sent out on a messaging Topic, thus employing a PubSub mechanism to broadcast the event to whoever is interested.

Materialized Views refers to utilizing the event and then constructing an aggregated/consolidated view, which is necessary to power a specific use case. To put it in another way, the data is materialized in a way best suited to a specific view. In the Booking example, another way to source the Fees due might be to have a separate service host the Fees Due API/view and construct the fees for each reseller based on the booking event. Let's say there are new requirements, say, bookings done in the last 10 minutes—then such a use case can be satisfied by a new API, which uses the same Booking event.

The trade-off in Materialized View versus denormalization is that one loses temporal consistency—the system eventually becomes consistent. The benefit is, of course, the extensibility of the solution.