As specified in the article DEL remains a blocking DEL. It's application code that calls UNLINK if a background release of memory is needed because of low laten

As specified in the article DEL remains a blocking DEL. It's application code that calls UNLINK if a background release of memory is needed because of low latency needs. However 50% of the blog post explains how the implementation avoids to create problems by releasing objects faster than you can allocate new ones in order to avoid the undetermined memory behavior[1]. Anyway memcached is a lovely product, I hope it will be developed more in the future so that users have a choice. But in the context of our discussion, there is no equivalent in memcached for this feature since objects are composed of a single allocation. You get the same if you just use Redis SET / GET / DEL commands. [1] This is also handled in the LRU code. If there is nothing to free but there are objects in the free list, the server waits for the background thread to make progresses to continue again. For expire and eviction of keys there will be explicit options where the user specifies if server-deleted objects should be deleted in a lazy or blocking way, with the old plain blocking as default.