I have a question with regard to the most appropriate architecture on couchDB for a Messaging app use case I have.
The use case is for a simple messaging platform which currently has one couch DB with all messages as documents. Each document has a “to” field indicating the intended recipients of the message. When a client app wakes up it queries the database for all new messages addressed to the specific user after the last check. This is achieved by querying the _changes feed with a normal filter checking for the presence of the user's id in a “to” field in the document.
As I understand couchDB’s operation, this requires the database to retrieve all documents for the changes feed after the last sequence and run the filter function against them. Since the likelihood of a new message in my use case is quite low, this would result in quite a large overhead (Lets say I have 100 000 users each getting two messages per day, it will require the DB to read all 200 000 message 200 000 times to support all users?)
Option 1: From what I read it is not possible to put a parametric filter on top of the _changes feed. This would be nice, since then I would have been able to use replication functionality to extract the messages. – Non Starter?
Option 2: Implement a view with a key combining the “to” field and the update sequence. I can then query this view for the user value and sequence > last sequence. – Here I am struggling to gain access to the document's update Seq from the Map function. – Is this viable?
Option 3: Implement a database on the server for each user and set up replication on the common database to each user specific database. The user then queries the _changes feed of her own database which only has messages directed to her, so easy. Now you need to maintain 100 000 x 2 replications on the server. This has other drawbacks, but could work.
From the above, which sounds like the most feasible/scaleable approach? Or am I missing another option?
Thanks
