Every system that serves requests has to pick a point on the throughput-versus-quality curve, and food is no exception. I got thinking about this watching kottu roti get made, because it is one of the clearest real-world examples of a made-to-order system I can point to.
Kottu is chopped flatbread stir-fried on a hot griddle with egg, vegetables and meat. The whole appeal is that it comes off the griddle hot, with crisp edges and a bit of chew, and you cannot pre-batch it and hold it under a lamp because the texture collapses in minutes. So a kitchen serving kottu is effectively running synchronous, per-request processing: each order is cooked fresh, which caps throughput but keeps quality high. The failure mode of trying to "optimize" by batching is exactly the soggy, reheated version everyone has had once and never ordered again.
The tradeoff shows up on the client side too. Made-to-order means you wait, and it means ordering ahead helps, which is why a spot like a kitchen that makes kottu roti in Toronto to order on weekends will tell you to give it a little lead time rather than pretend it can be instant. That is not a limitation to engineer away; it is the constraint that guarantees the output is good.
The general lesson, and the reason I keep coming back to food as a systems metaphor: some quality properties are inherent to synchronous processing and cannot survive batching. Know which parts of your pipeline are kottu, and stop trying to cache them.
Top comments (0)