Pulsar+Flink, Pulsar+Spark, or Pulsar Functions no longer support effectively-once (or exactly-once) semantics. Yes, Pulsar supports de-duplication of data and an idempotent producer, but it isn’t enough for exactly-once semantics. The current functionality supported is only suitable for producing one message to just one partition, and you can implement such semantics manually with a DIY setup in only a few edge cases. For instance, you can’t produce numerous partitions to a partition atomically, which also means that interaction with the state isn’t exactly-once.
However, Pulsar supports at-most-once semantics where you might lose data and at-least-once semantics, where you won’t lose data, but you might see duplicates.
Memphis supports two delivery semantics: at least once and exactly once. The former is possible because of a combination of published messages that persist on a station and the acknowledgement of each message that the clients receive and process.