Evaluate whether my app actually needs read replicas or other read-scaling infrastructure, using evidence instead of anxiety. Gather first: current database CPU, memory, and connection utilization under real or load-tested traffic; the read/write ratio of my actual query traffic; the slowest queries and whether they'd be fixed by an index instead of hardware; and cache hit rates if caching exists. Then apply the decision in order: fix slow queries first (indexes, rewrites, pagination), add caching for hot reads second, scale the primary vertically third, and only then consider replicas. If the numbers say a replica is justified, plan it properly: which reads can tolerate replication lag (feeds yes, read-your-own-write no), how the app routes reads versus writes, and what happens when a replica falls behind. Don't add a replica because it sounds like what serious apps do. Don't route reads to a replica where the user expects to immediately see their own write; that's how 'my post vanished' bug reports happen. Deliver: the utilization evidence, the decision with reasoning, and if replicas are justified, the read/write routing plan with the lag-tolerance rule per feature.