When you say “Queries may return stale data” are you:
a) talking about the fact that “Couchbase queries could return stale data”?
b) the fact that your application can deal with some stale data on some queries in your application?
To answer directly your question, as you have seen in the documentation, the document are eventually indexed and the queries are eventually consistent
Everything occurs asynchronously on the server side: for performance and resource consumption reason.
If your application is ok with stale data you can just let the system as it is with the default:
query with a stale = “update_after”
and the auto update of the index every 3s or 5000 operations.
This even if you have lot of writes, should allow you to have very good performance and good views of your data.
When you say that you have a “high number of document writes” could you tell us more about that? What is “high” ?
So I would start with the default and see if this fits your needs. (keep it simple) and only for some queries when it is really necessary change the stale parameter.
With regards to stale data, the App can cope with potentially stale data in the results, so has no issue if couchbase queries return stale data.
If the defaults should give good performance for this type of use case then I’ll keep it simple as you suggest and monitor performance once under load.
My statement about the number of writes was more about my expectation of the usage profile, I am not in production yet so do not have hard figures for document writes which will depend on service take-up.
I am now confident that I can move forward with this model and I am not building any issues into the design.