A grants team asks for exactly-once end-to-end processing of every subsidy event across producers, Kafka, and multiple sinks. What tradeoff should architects communicate?
Select an answer to reveal the explanation.
Short Explanation
Wanting every subsidy event once sounds tidy, but end-to-end exactly-once is the fancy clockwork—pricey and intricate. At-least-once plus careful sinks is often the practical civic path. Know the tradeoff exists.
Full Explanation
Exactly-once end-to-end processing across producers, Kafka, and multiple subsidy sinks is substantially harder than at-least-once and adds real protocol, idempotency, and coordination complexity. Architects should communicate that tradeoff clearly to grants stakeholders who ask for a guarantee that sounds free. At BDPC awareness level, recognizing the cost and limits of exactly-once is as important as knowing the slogan.
Exactly-once is not free merely because disks are plentiful; durability and duplicate suppression are different problems. Claiming at-least-once never needs consumer design because duplicates cannot occur contradicts standard messaging semantics. Asserting that messaging systems guarantee exactly-once without idempotent sinks or coordinated protocols oversells broker features and understates application responsibilities.
Exam caveat: many civic systems correctly choose at-least-once plus idempotent consumers as a pragmatic middle path rather than chasing end-to-end exactly-once across every sink. Operational check: inventory each subsidy sink for idempotent keys or transactional write support, document where duplicates would double-pay or double-count, and decide explicitly where at-least-once with idempotency is sufficient versus where stronger coordination is required.