It's quite durable. CouchDB has pure tail append storage and will fsync every update and batch concurrent updates into a single commit. It can get fairly close to a drives max sustained write speed.
The point of this article is queuing requestd at the webtier until you have enough to swamp the HTTP transport overhead to CouchDB. If the website crashes you are going to lose that data.
I'm not sure I understand. CouchDB won't lose any committed (fsynced) data when it crashes. And when configured, it won't return a success until it's committed. It's completely durable.
edit: Oh I see, the stuff written in the clojure side won't be committed. If he wanted to write each one synchronously to CouchDB, that would work and CouchDB would still batch up the concurrent updates while writing.
"As requests come in, instead of connecting immediately to the database, why not queue them up until we have an optimal number and then do a bulk insert?"
Judging by the code, it looks like he stores about 50 documents before sending them to CouchDB. I believe the original poster was asking about the durability of Clojure STM, not Couch DB.
