Optimistic locking is useful for interfaces where you have a person interactively updating a record. You check out a copy of the record, give the user all the time in the world to work out what changes they want to make, then, when the user goes to apply the changes, if the record was changed after you checked out a copy, then you deny the update and force the user to start over. Those last steps need to be done atomicly which is usually where locks come into play. But just ensuring that update operations for any given record get processed one-at-a-time from a single queue will also make updates atomic.

To handle delete requests with this, you'd need to keep a place-holder for deleted records that consisted only of the revision number. I'd just let the external code decide what it wants to use as a place-holder for deleted records and use the update operation instead of the delete operation.