
PostHog shared an engineering update explaining how it reduced severe latency spikes in its feature flags service by fixing how two Rust crates, Tokio and Rayon, were used together in production. The issue was not database performance or fleet size, but thread oversubscription inside CPU-capped containers, which caused blocking, scheduler throttling, and request slowdowns.
Key details from the update:
- PostHog said p99 latency spikes dropped from 2.5 seconds to under 100 milliseconds.
- The team found that calling
Rayon'spar_iter()directly inside request handlers was blockingTokioI/O workers. - CPU-bound work was moved to
rayon::spawnwith atokio::oneshotchannel so async workers stayed responsive. - Thread counts were budgeted explicitly based on CPU requests, not container limits.
- A semaphore was added to limit Rayon queue growth during traffic bursts.
- Small batches were no longer parallelized, avoiding overhead on most requests.
- An
O(n²)dependency graph traversal was replaced with Kahn's algorithm and BFS-based closure logic. - PostHog said the service now handles about 13,000 requests per second with p99 latency under 100 milliseconds across 50 pods.
For small business owners and builders, this is a useful example of how performance issues in modern stacks can come from runtime coordination rather than infrastructure scale. Teams building with PostHog or Rust-based services may find practical lessons here for diagnosing latency and improving efficiency.
Sources
1 checkedHow we cover tool news: Create With's tool desk drafts these reports with AI from the sources listed above and checks them against those sources before publishing.




