proomt

Search

Search posts, papers, and topics

Hall of Fame

Hall of FameJeffrey Dean, Luiz André Barroso20131 min readpaperintermediate

The Tail at Scale

Summary

The paper defines “tail‑tolerant” systems that keep interactive latency (≤100 ms) low even as services scale to thousands of servers, and surveys the main causes of latency outliers. It shows that techniques such as request replication, hedged requests, and resource isolation can dramatically shrink the latency tail with modest overhead, enabling higher utilization without over‑provisioning.

  • Tail latency becomes the dominant performance factor as system size and load increase.
  • Request replication and hedged requests can mask slow components, reducing the 99th‑percentile latency.
  • Isolating resources (CPU, network, memory) prevents noisy‑neighbor effects that cause latency spikes.
  • Tail‑tolerant designs let services run at higher utilization, cutting wasteful over‑provisioning.

Any engineer building large‑scale, latency‑sensitive services (search, AR, etc.) must manage tail latency to maintain user experience and cost efficiency.

8/10

Related reading

  1. We're making Tailscale faster

    Tailscale is cutting memory overhead for small packets, adding a multi‑queue pipeline for routers and exit nodes, using Linux’s writev, and introducing netmap caching to speed up startup. These changes give ~5 % throughput gains now and larger gains in upcoming releases.

    Tailscaletailscale.com7 minHN3
  2. On Designing and Deploying Internet-Scale Services

    James Hamilton’s 2007 paper distills a set of concrete best‑practice tenets for building operations‑friendly, internet‑scale services—design for failure, keep things simple, and automate everything. Applying these guidelines (commodity hardware, single‑version software, redundancy, multi‑tenancy) enables ratios of thousands of servers per administrator while maintaining reliability.

    Hall of Fameusenix.org43 minpaper
  3. Postgres on NVMe: performance and the convergence of transactions and analytics

    Local NVMe storage cuts Postgres I/O latency from ms to µs, yielding ~9× higher TPS and 10× lower transaction latency on a 482 GiB pgbench workload. The gain comes from reduced IO wait, not more CPU work. To retain durability, combine NVMe with quorum synchronous replication and continuous WAL archiving (WAL‑G). For analytics, offload scans to ClickHouse via WAL‑based CDC (pg_clickhouse or the ne…

    ClickHouseclickhouse.com8 min
  4. Server Monitoring in the age of AI: What static thresholds miss and how adaptive monitoring fixes it?

    Static CPU/memory thresholds generate noise because workloads vary by time‑of‑day, day‑of‑week, and long‑term trends. Adaptive monitoring learns per‑server baselines (using simple ML on historic metrics) and creates dynamic thresholds plus anomaly alerts. ManageEngine OpManager’s Zia engine is presented as a turnkey AIOps solution that auto‑learns baselines, lets you set sensitivity, and adds ale…

    SitePointsitepoint.com6 min
  5. How we tracked down a 16-year-old SQLite bug

    Tailscale experienced 19 SQLite database corruptions over six months due to a 16‑year‑old bug in SQLite’s WAL checkpoint logic. The single‑writer, Go‑driven shard architecture forced them to add forensic telemetry, a transaction‑logging replay pipeline, and work directly with SQLite core developers to isolate and fix the issue, dramatically reducing downtime.

    Tailscaletailscale.com14 minpostmortemHN1223239