> 1. you need to use a Pub/Sub implementation that does support exactly-once delivery (only MySQL/PostgreSQL for now), To implement exactly-once delivery you f

> 1. you need to use a Pub/Sub implementation that does support exactly-once delivery (only MySQL/PostgreSQL for now), To implement exactly-once delivery you first need exactly once delivery. But this project doesn't implement exactly once delivery. > It can be triggered by calling the http://localhost:8080/count/{counterUUID} http://localhost:8080/count/{counterUUID} endpoint. Oh, but what if my network goes down right after I sent that request? Did it succeed? There is no way of knowing. So now I have to pick between sending again (at least once) or not (at most once). You can get exactly once delivery. But you need to involve request IDs which you haven't done here. Imagine something like this: PUT http://localhost:8080/count/{counterUUID}?request-id={requestUUID}. The requestUUID must be unique per counter. It should be generated when the action occurred (like when the user clicks a button) and should be reused for retries. (Of course this will still be foiled by a user clicking a button multiple times) Now the server does: INSERT INTO increments(counter_id, request_id, counted) VALUES (:counterUUID, :requestUUID, FALSE) ON CONFLICT DO NOTHING Now instead of deleting the record you just mark `counted = TRUE`. In theory you can never delete records from this table. In practice you can add a timeout after which double-counting is acceptable.