Architecture options for CouchDB messaging app -

i have question regard appropriate architecture on couchdb messaging app use case have.

the use case simple messaging platform has 1 couch db messages documents. each document has “to” field indicating intended recipients of message. when client app wakes queries database new messages addressed specific user after last check. achieved querying _changes feed normal filter checking presence of user's id in “to” field in document.

as understand couchdb’s operation, requires database retrieve documents changes feed after last sequence , run filter function against them. since likelihood of new message in use case quite low, result in quite large overhead (lets have 100 000 users each getting 2 messages per day, require db read 200 000 message 200 000 times support users?)

option 1: read not possible put parametric filter on top of _changes feed. nice, since have been able use replication functionality extract messages. – non starter?

option 2: implement view key combining “to” field , update sequence. can query view user value , sequence > last sequence. – here struggling gain access document's update seq map function. – viable?

option 3: implement database on server each user , set replication on common database each user specific database. user queries _changes feed of own database has messages directed her, easy. need maintain 100 000 x 2 replications on server. has other drawbacks, work.

from above, sounds feasible/scaleable approach? or missing option?

thanks

i'd go option 2. instead of document sequence id (which don't think can view functions), add date/time field message documents?

if you're worried clock skew in clients (which should have posted comment answer instead of trying edit it, got rejected), can apply tolerance in retrieval. i'm assuming wouldn't bad pull in few messages you've seen.

(i wouldn't worry clock skew, don't know kind of clients you're going working with.)