How Routing Reads to Replicas Cut a Postgres Primary's CPU from 90% to 20%

A development team spent nearly a year running all database queries — reads and writes — through a single primary Postgres instance, which eventually pushed CPU usage to 85–90% during business hours and slowed customer-facing endpoints. The team deployed two read replicas using streaming replication, a process that took only an afternoon, but spent two weeks auditing every database call to determine which reads were safe to offload. To avoid showing users stale data after a write, the team implemented a five-second primary-pinning window for requests immediately following a write within the same user session. Sensitive reads — including authorization checks and financial calculations — were also kept on the primary, while analytics, search, and most page-load queries moved to replicas without any user-visible impact. Replication lag was elevated to a first-class monitored metric, with alerts set at two and ten seconds to protect the correctness assumptions the new routing logic depended on.