> - Have we considered a metadata store to persist and dedup deletion > requests instead of the system topic? Why is the system topic the better > choice than a metadata store for this problem? If we use the metadata store to store the middle step ledger, we need to operate the metadata store after deletion every time. And we need a trigger to trigger deletion. In the broker, it may have lots of topics, the ledger deletion is also much. Using the metadata store to store it may be a bottleneck. Using pub/sub is easy to implement, and it is a good trigger to trigger deletion.
> - How does Pulsar deduplicate deletion requests(error out to users) while > the deletion request is running? The user only can invoke `truncateTopic`, it's not for a particular ledger. The note: "The truncate operation will move all cursors to the end of the topic and delete all inactive ledgers." It's just a trigger for the user. > - How do users track async deletion flow status? (do we expose any > describeDeletion API to show the deletion status?) Why need to track the async deletion flow status? The ledger deletion is transparent for pulsarClient. In the broker, deleting a ledger will print the log `delete ledger xx successfully `. If delete failed, it print the log `delete ledger xxx failed.`
