After mentioning Mozilla Raindrop as a CouchDB case study and using it in an informed comparison of CouchDB and MongoDB, I’m filing this one under lessons learned:
- CouchDB isn’t central to this architecture, but that’s probably good for Couch’s reputation — we were misusing it, and causing it to behave poorly. We still think it’s awesome, we just weren’t able to make it work for this use case (lots of writes & reads, only per-user data).
- Specifically, we fell prey to the “ooh, shiny hammer!” effect, and used CouchDB for everything, including storage of temporary variables, as a message queue, and as a state machine of sorts. Given that our ability to understand the performance implications of some of these design decisions is limited, we’re stepping back from innovating on the back-end architecture, and “falling back” to a system that we can profile and optimize more easily.