Since in event-sourcing the event store does not use transactions, how can we guarantee that, if our business logic crashes, after it publishes an event, that the event won't be published twice when restarting the service?
In the case that the message is published and delivered twice, how can it be de-duplicated?
I don't know that the event store does not use transactions. I've seen transactional writes to ensure that the expected event version is being written.
If you are expecting at-least-once delivery, which I assume you are, then you must handle deduplication. It is sometimes recommended to maintain an index of all processed messages as a de-duping approach, but it is not completely safe in that you just minimize the section of code in which a duplicate can be created, but don't remove the possibility altogether. If you process a message, but do not update the index then you will reprocess the same message again. You should instead make all of your actions idempotent. That is, performing the same action twice will produce the same resulting state. If you process the same message twice, it should only update state once.