Reading about their fix with a "magic" number it seems that when there was corruption - the file would never be deleted again since you've lost information at this point. (As they claim, even if the magic number went back to "0" you would still need to keep the file.)

Rather than this questionable solution, why not create an transaction-like system where a delete would result in a tombstone/marker placed on the email database with a rollback mechanism if one or both of the services crashed.

For example, an index marking the email as deleted, then you delete the file, then if the file was successfully deleted actually clear the email record.

So the email table would be: {id uint64, ... deleted bool}

1. If the file delete service failed, then unmark the deleted index (or try again).

2. If the marking the email as deleted failed, then you're back to square one with no change.

3. If the email is marked, the file is deleted, but actually deleting the email failed. Restart/Tryagain/etc until you get that pesky email record removed.