Akka Persistence Duplicate Suppression Configuration Scope

Akka Persistence event-sourced actors can persist duplicate events when a command is retried after a failure, because the framework does not provide built-in duplicate suppression. The documented pattern embeds a unique requestId in the command and maintains a set of processed identifiers in actor state, but the exact configuration boundary between framework guarantees and application-level deduplication is not clearly delineated.

In Akka 2.6.x, persistAsync may interleave writes from concurrent commands, and ordering behavior is not fully specified for retry scenarios. The persistenceId is required for each persistent actor, yet the framework does not enforce uniqueness across actors, so accidental reuse can also yield duplicate journal entries. Plugin choice, such as JDBC or LevelDB, may influence how duplicates are detected or logged, but no default plugin setting eliminates the need for application-level checks.

Given these constraints, is retry safety achieved through a specific persist versus persistAsync configuration, a documented plugin setting, or strictly through application state? Should requestId tracking be considered mandatory whenever commands are retried, or are there configurations where the journal itself prevents duplicate writes?