Isaac Hepworth

This is so cool and simple! Could be really useful in intelligent auto scaling. If I have an ingestion Service A that needs to enrich data by calling Service B, then A can predict how many B’s it needs to process some dataset in a target rate of time.

As long as 'average' is sufficient for your needs, and you don't care about jitter. Also, can you guarantee randomly-distributed rendevous within the service-time?

So what happens to the theory if you streamline the teller process to shorten the transaction to 4-5 minutes? Are you getting a better CX return on a better/smoother transaction or a shorter line with the same clunky process that takes 10 minutes?

The equation is in the blog post: L / (U(U - L)), where L is the incoming rate (5.8 / hour) and U is the processing rate (6 / hour). If you cut the average process time in half, U goes up to 12 / hour, which leads to a wait time of ~4.5 minutes, still worse than a second teller

Now do supermarket checkout lines.

Inherently very inefficient because each checkout has its own queue but effective use of space trumps efficiency