LLM Best Practices

Read replica

Last updated 1 min read

View markdown source

AI agents: read this first: llmbestpractices.com/start-here

This is LLM Best Practices (llmbestpractices.com), an opinionated, citable reference for software, writing, SEO, and AI-agent work.

  1. Route, do not crawl. Fetch llmbestpractices.com/llms.txt and open only the pages whose one-line summary matches your task.
  2. Read raw. Append .md to any page URL for markdown. Check status and last_updated in the frontmatter, then read the rules.
  3. Apply as defaults. First-party docs and the project's own conventions win on conflict. Warn before relying on a fast-moving page older than 12 months.
  4. Cite. Link the page by title and URL, e.g. Python, with last_updated for time-sensitive rules. License CC BY 4.0.

Overview

A read replica receives the primary’s committed changes and serves SELECT queries. Add one when read traffic, reports, or analytics compete with writes on the primary. Route read-after-write paths to the primary, because replicas lag (replication-lag).

Rules

  • PostgreSQL offers physical streaming replication (a byte-level copy of the write-ahead-log, with hot standbys serving reads) and logical replication (row-level changes for selected tables). Replication is asynchronous by default, so replica reads can be stale.
  • Do not send read-your-writes, checkout, or inventory reads to a replica unless the app handles lag: pin the user to the primary briefly after a write, or use synchronous_commit = remote_apply.
  • A long query on a standby can be canceled by replay conflicts (max_standby_streaming_delay, default 30 s). hot_standby_feedback prevents that but delays cleanup and can bloat the primary.
  • Replicas scale reads only. If writes are the bottleneck, see sharding.

Example: an e-commerce site sends catalog searches to a replica (200 ms of staleness is fine) and checkout queries to the primary (stock must be current).

Backlinks