couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Cox <>
Subject Re: Architecture of a messaging app using Couchdb
Date Tue, 28 Nov 2017 15:00:19 GMT
Hi Sachin,

I work on a teaching app called Quizster that handles some of the same
concerns. Here is my 2 cents:

On Tue, Nov 28, 2017 at 6:37 AM Sachin Divekar <> wrote:

> Hi,
> I have been studying a possibility to use Couchdb for a realtime messaging
> app. The architecture I am thinking about is as follows. The app will
> access only the local offline database using Pouchdb which is in continuous
> replication with a remote Couchdb cluster. On the server, it'd be one
> database per user. The app, in addition to conversations also has other
> active objects like tasks, notes etc. I just want to have a discussion with
> some experienced Couchdb users if such architecture makes sense.
> My primary concerns are following.
> 1. I am thinking of keeping shared objects in every participant user's
> database. e.g. a group chat will be present in each of the participant's
> database or a task can have multiple users assigned to it. I am not sure
> how to replicate the changes made by one user on a task in his database to
> other participant's database. Perhaps using filtered replication but I am
> not sure.
GC: I think you have a few options here:
1. You can use filtered replication to replicate the docs, where you'd
probably need a replication for each pair of users who are sharing the docs
to replicate to and from the respective user's DBs.
2. If you can identify a common group, e.g. in our app we have classes, and
don't need this group to write to these common docs then you can use a
database to replicate docs from a user DB to this "group" database. Users
could then read from this group DB. Perhaps in your case you can think of a
group like a Slack organization or channel. You can then use a role to
restrict read access to this group DB. You'd still need a replication per
user-group, but you'd probably need a lot less of them.
3. You could create a custom API, instead of writing data with PouchDB,
(just use PouchDB for reading) that you call when the user sends a message
that saves the message to all the needed databases. This has the distinct
disadvantage that without some serious work on your side that you app
wouldn't work offline.

> 2. Will the load of continuous replication of a few thousand databases be
> handled smoothly?
GC: This is great question and this load is definitely an issue. The good
news is that we just open sourced our solution for this: Spiegel

> 3. How to deploy filters, views etc on all the databases because
> essentially they will be same for all the databases.
GC: We create migration scripts that use Slouch StreamIterators
to iterate through all the target databases and create the filters and

> Looking for some advice.
> Thank you.
> Regards
> Sachin

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message