Tiffin's order data is written in one place: checkout. But it is read in a dozen. The customer wants their order history. The kitchen tablet wants today's open orders, oldest first. Support wants to search by phone number. The city operations team wants a live map of every order waiting for a rider.
Each of these screens wants the same data in a different shape. If they all read the same normalised tables that checkout writes to, every screen turns into a pile of joins, and every new index added for one screen slows down writes for all of them. This lesson is about splitting those two jobs apart.
One model, many jobs
A table designed for writing has to protect the rules. An order can't be accepted twice. A coupon can be used only once per customer. Stock can't go below zero. So the write model is normalised, with constraints and foreign keys, and each fact lives in one place.
A screen designed for reading wants the opposite. It wants everything it shows in one row, already joined, already sorted, maybe already counted. The "orders waiting for a rider" map wants order id, restaurant name, restaurant location, minutes waiting and the city zone, in one query, with no joins.
Both goals are reasonable. They just pull the same table in different directions.
CQRS (Command Query Responsibility Segregation) means using one model to handle changes and separate models, shaped for each screen, to answer reads.
The name is a mouthful. The idea is simple: writes go to the model that checks the rules; reads come from models built for reading.