Latency compounds when the time spent in one component affects when another can finish. In serial compounding, components execute in sequence: each dependent stage must wait for the preceding stage. Queues can add delay too, including the wait for an operating system scheduler to resume an application after data arrives. section 2.4
HTTP request processing
An HTTP server must parse a request’s method and path before it can route the request to a handler. Faster parsing reduces this serial delay. Routing cannot start before parsing produces its result, but SIMD instructions can parallelize work within the parsing stage. section 2.4
Independent tasks can instead run in parallel, but completion still waits for the required results. A MapReduce map phase can process input partitions independently; the job’s latency can depend on its slowest task. Parallelization changes how delays compound—it does not make every delay disappear. section 2.4
Replication across a quorum
In Viewstamped Replication, a client sends a request to the primary, which logs the operation and sends Prepare messages to replicas in parallel. Replicas return PrepareOK acknowledgments; the primary waits for a quorum before applying the operation and replying. Client–primary distance adds latency, while distant replicas can raise quorum acknowledgment latency. Placing replicas across data centers supports high availability but creates a latency trade-off. section 4.7
Figure 4.8 Example of Viewstamped Replication normal operation message flow
Follow the normal-operation message flow to locate the client request, parallel Prepare messages, quorum acknowledgments, and reply. section 4.7
To analyze a request, identify which stages must finish before the next can begin and which work can proceed independently. Then target the relevant delay: speed up a required stage, parallelize work within it, or account for queues and quorum placement. section 2.4 section 4.7
