A parking-sensor topic uses at-least-once delivery, so a garage analytics consumer may see the same occupancy event more than once. What consumer practice matches that delivery model?
Select an answer to reveal the explanation.
Short Explanation
At-least-once means the mailman might knock twice with the same letter. Your garage app needs a stamp check—process by meter or event id so a second copy does not invent phantom cars. That keeps dashboards honest when delivery retries happen.
Full Explanation
At-least-once delivery means retries after failures can present the same occupancy event more than once, so garage analytics must apply idempotent updates keyed by stable meter or event identifiers. Idempotent processing ensures a duplicate delivery refreshes the same occupancy state instead of inventing phantom cars or double-counting spots. That consumer practice is how civic parking pipelines stay honest when brokers redeliver after crashes, rebalances, or acknowledgment timeouts.
Assuming every message is unique and blindly incrementing counters converts delivery retries into metric corruption—exactly the failure mode at-least-once systems create under stress. Disabling acknowledgments so the broker never redelivers after a crash does not remove duplicates in general and can worsen loss or stuck offsets depending on client settings; it is not a substitute for idempotent business logic. Dropping all redelivered messages without checking business keys risks discarding the only surviving copy of a legitimate event after a partial failure.
Exam caveat: idempotency keys must be stable and unique for the business fact; weak keys (for example, wall-clock timestamps alone) can either collapse distinct events or fail to collapse duplicates. Operational check: replay a known occupancy event twice into a test consumer and confirm counters, last-seen timestamps, and downstream dashboards move once, not twice, for that meter key.