Operators propose promoting RDS read replicas to “decouple” write-heavy permit processing spikes. What clarification should the architect make?
Select an answer to reveal the explanation.
Short Explanation
Replicas are extra librarians for people reading the card catalog; queues are the inbox that keeps writers from shouting over the desk. Promoting a reader into a magic write-decoupler mixes up the tools.
Full Explanation
Read replicas scale read traffic; they do not decouple write-heavy permit processing spikes. The architect should clarify that RDS read replicas offload SELECT load from the primary, while queues such as Amazon SQS absorb and decouple write-side work from producers so processing can drain asynchronously. Promoting replicas as a “write decoupler” confuses two different tools.
Claiming read replicas both scale writes linearly and replace all messaging for asynchronous work fails by concept: replicas do not provide linear write scale-out on the primary’s write path, nor do they replace queues. Deleting the primary database and writing only to read replicas fails because replicas are not writable primaries in standard RDS replica usage and cannot be the sole write target for loose coupling. Replacing both replicas and queues with larger NAT gateways fails because NAT gateways address egress networking—not database read scale or application back-pressure decoupling.
Exam caveat: Replicas → read scale; SQS/SNS/EventBridge → decoupling and buffering writes/events. Do not treat read replicas as write absorbers or messaging replacements; NAT size is unrelated.
Operational check: Direct heavy read queries to replicas with appropriate lag tolerance, send spike-prone write jobs through SQS consumers, watch primary CPU/IOPS and queue depth separately, and never point writers at replicas expecting write scale. If operators “decouple writes” only by adding replicas, the clarification still needs to land.