Route search/browse at the Aurora reader endpoint (after editor removal + reader instance)

[skearnes]

Summary

Route the interface's search/browse database connection at the Aurora reader endpoint instead of the writer, so read traffic stays off the primary and is distributed across read replicas.

This is deferred, not done. It should be picked up only once both preconditions hold:

1. A reader instance exists in the Aurora cluster. Today the cluster has a single instance (cluster-instance-0), and Aurora's reader endpoint routes to the primary when there are no replicas — so switching now buys nothing.
2. The editor has been removed. The interface container runs two apps behind nginx that share the single POSTGRES_HOST env var: the FastAPI search/browse API (read-only) and the Flask editor (ord_interface/editor/py/serve.py), which does INSERT/UPDATE/DELETE on the editor DB. Pointing the shared var at a read-only reader replica would break those writes. (The editor is slated for deletion, and we don't want to actively support its writes — hence the ordering.)

Where the change lives

The connection host is injected by the ord-infrastructure Pulumi stacks, not by ord-interface code — ord_interface/api/search.py get_cursor() just reads POSTGRES_HOST. The change is:

1. ord-infrastructure stacks/backend/__main__.py — export the reader endpoint:

   pulumi.export("rds_reader_endpoint", cluster.reader_endpoint)

2. ord-infrastructure stacks/interface/__main__.py — point POSTGRES_HOST at it:

   awsx.ecs.TaskDefinitionKeyValuePairArgs(
       name="POSTGRES_HOST", value=backend.get_output("rds_reader_endpoint")
   ),

3. Deploy backend first (to publish the new output), then interface.

Tracked here because the trigger (editor removal) is ord-interface work.

---

🤖 Generated with Claude Code