Why isn't a single-process test enough for event-handling code like payment completion?

When you feed the message only once there is no further message to arrive, so it looks fine in normal use. The issue only shows up the moment the same message is redelivered, which you confirm by feeding the same event twice.

How do you verify handling that withstands redelivery?

Process an event for the same order twice, then assert that the balance dropped by only one round's worth. The result must match what you get when you process it only once.

What does the 'at-least-once delivery' condition mean?

It means the messaging system may send the same message two or more times so as not to drop it. It is the standard real-world assumption that the receiving side must withstand duplicate arrivals.

Deduct Points on a Payment-Completed Event

Your task

When the payment system finishes a payment, it sends a "payment completed" message. Our points service receives that message and must deduct the user's balance by the points for that order. Complete PointConsumer.handlePaymentCompleted(event). The event contains orderId, userId, and points. Subtract the points you received from that user's balance. Note: the payment system promises to deliver the message "at least once." Depending on network conditions, the same message may arrive once more, late.

Ground rules

•Use a single instance and an in-memory store.
•Users and orders are identified by the event's userId and orderId.

Not required

•Policy for insufficient balance, and refund or cancellation messages.
•Authentication, authorization, and rate limiting.
•A distributed setting where multiple instances receive the same message at once.

▶About this challenge

This challenge has you build a NestJS consumer that deducts user points from a payment-completed event. The payment system delivers the message at least once, and the same message may arrive again depending on network conditions. You complete the consumer's handling of the payment-completed event and use the in-memory store as the single source of truth for balances.

This problem is about handling where "the same message arriving again must be reflected only once." For resources where something that happened once must be applied only once — points, balances, inventory — code can look fine when the message arrives a single time, yet the real test is the moment the same message is redelivered. Verifying code like this means going beyond a single-process check: you feed the same message twice and confirm the result is reflected only once.

Why isn't a single-process test enough for event-handling code like payment completion?: When you feed the message only once there is no further message to arrive, so it looks fine in normal use. The issue only shows up the moment the same message is redelivered, which you confirm by feeding the same event twice.
How do you verify handling that withstands redelivery?: Process an event for the same order twice, then assert that the balance dropped by only one round's worth. The result must match what you get when you process it only once.