So assuming that
1) Couch requests take a while
2) We make multiple requests to couch when doing make_search_results

there is a race condition/consistency problem here, and a performance problem.

If at:
t0 we start a series of identical search requests,
t1 we update an element in the search from V0 to V1
    after t1 we continue to receive identical search requests
t2 the first search request updates the cache
t3 the last search request started before t2 finishes
t4 (TTL + t3) 

Between t0 and t2 all requests will miss cache, hit couchdb, and update the cache value when they complete.
Requests before t1 may return the old result V0, requests after t1 but before t2 will return the new result V1
Requests after t2 will use the cache, but may return V0 or V1 depending on what the latest cache update from earlier requests. As requests from between t0 and t2 complete, the cache value will be updated with whatever results they computed. 
Requests after t3 will return V0 or V1 depending on what the last update contained; which one will be non-deterministic.
Requests after t4 will return V1

So this introduces a transient state where we may return the old result, a new result for a little while, then the old result again, and then after TTL, the new result. I think in poorly designed systems this may generate some unexpected results. 

Also, if a large number of requests are closely spaced, we might not get the advantages of caching we hope for. It largely depends on how tightly things are clustered, and the relationship between the typical couchdb response time under load and the TTL; if the TTL is long in proportion to the couchdb service time we will be fine. 

To be clear, I can't think of a caching system with the simplicity and elegance of this one that doesn't exhibit this kind of consistency problem. I'd much rather have this now than the perfect thing later. I think we'll be fine if we're willing to tell customers that if their system is sensitive to this kind of stuff it's broken.