Smart-meter ingest must keep accepting readings even if the downstream database is briefly unavailable. Which fault-tolerance pattern fits?
Select an answer to reveal the explanation.
Short Explanation
When the database takes a coffee break, don’t bounce the meters—park the readings in SQS and drain the queue when the DB is back.
Full Explanation
Buffering smart-meter readings in Amazon SQS so producers keep accepting data while consumers catch up after the database recovers is the fault-tolerance pattern that keeps municipal ingest alive through brief downstream outages. SQS works because it provides durable, decoupled storage of messages: meters or edge gateways (or an ingest API in front of them) can continue enqueueing reads when RDS/DynamoDB maintenance or failover makes the database briefly unavailable. Consumers drain the backlog when the database returns, preserving data that would otherwise be refused at the edge. For utilities and cities, that queue is the difference between a maintenance window and lost interval data.
Having meters open synchronous SQL connections and fail the read when the DB is down fails by concept because it couples field ingest directly to database availability and drops or blocks readings during every blip. Dropping all readings during DB maintenance windows with no durable staging fails because intentional data loss violates the “keep accepting readings” requirement. Writing meter reads only to instance store on a single EC2 host without replication fails because instance store is ephemeral and a single host is a SPOF—reboot or hardware failure loses the staged data.
Exam caveat: SQS buffering needs consumer idempotency and backlog alarms; an unbounded queue without scale-out consumers only defers failure. Operational check: place SQS between ingest and DB writers, simulate DB unavailability, confirm enqueue success and zero meter-facing errors, then measure drain time and DLQ rates when the database returns.