Route monolith reads to replicas without code edits

Drain safe reads from an overloaded primary by running a parallel monolith and routing selected endpoints to replicas.

Parallel Monolith Read Drain

When a legacy monolith sends too many reads to a master database, you do not always need to fix every call site first. You can run the same code under a different environment and route known-safe read endpoints to it.

Modern code explicitly uses replicas for reads, but old paths still hit the master. The master is overloaded by reads that could tolerate replica lag.

Run two copies of the monolith:

Copy Config --- --- Monolith 1 DEFAULT DB = master Monolith 2 DEFAULT DB = replica

Then route with an API gateway:

KrakenD-style endpoint config supports path and method-specific routing, which is enough for this class of migration.

No legacy code edit required. Rollout is per route. Rollback is a gateway rule change. Misclassified writes fail against the replica instead of silently overloading master. The team gains time to do proper query cleanup later.

Only move routes that tolerate stale reads.

read-after-write checkout flows, account balance reads, confirmation pages immediately after mutation, idempotency/retry endpoints that read and write together.

profile display with acceptable lag, static catalog-like reads, dashboards with freshness labels, account metadata where stale reads are not correctness-critical.

Route Classification

Before routing a path to the read-drain monolith, classify it:

Question Safe Answer --- --- Does it mutate state indirectly? no writes, no audit side effects required Does it require read-after-write consistency? no, stale data is acceptable Does it use transactions or locks? no master-only behavior Does it depend on session state updated by the request? no Can replica lag be shown or tolerated? yes

If the endpoint is a GET that increments counters, touches "last seen", refreshes tokens, or lazily creates records, it is not a pure read. Either keep it on the master copy or remove the side effect first.

Start with metrics for master read QPS by endpoint if available. Add the second monolith with replica-default config. Route one low-risk read endpoint. Watch master QPS, replica lag, error rate, p95/p99 latency. Expand route list gradually. Later, clean the actual legacy code with evidence from the routed endpoints.