Couchbase Microservice Architecture

I’ve read a lot of articles about having a datastore per microservice. I’m going to use this approach but want to know the best way to go about it using Couchbase Sync Gateway since I want to use Sync Gateway REST API calls both from mobile AND backend server apps. I am thinking that the simplest way to go about this is to have one Couchbase cluster (3-n Couchbase Server instances) with maybe 2-3 buckets. A bucket for sessions maybe, another for all of my data, and maybe some others later. For each microservice’s “database”, instead of having different physical clusters for each, I’m thinking I should just put all of the data in one bucket and differentiate the databases and tables by document fields. So maybe I would have something like:

{
database: 'person-api’
doc_type: ‘Person’


}
I would also have multiple database entries for each service all pointing to the same bucket in my sync-gateway config file. Then I would need to set up ACLs or some kind of controls that would only allow the backend server applications to access their own databases (so the ‘election-api’ server could only read/write docs with the corresponding database property). This would all have to be through Sync Gateway, for writes at least (I might do most reads using the sdks instead).

Sync Gateway is still a bit confusing to me and I’m not sure if this is the best approach. Would I just use channels as a sort of ACL? Is this just a bad approach to begin with? Any suggestions? thanks!

I imagine one of more of the mobile guys will be able to give a bit more of an in depth answer, but this is the part where you’ll start having issues:

I would also have multiple database entries for each service all pointing to the same bucket in my sync-gateway config file.

Sync Gateway expects one bucket per database. The thing is, the bucket isn’t just used to contain the exact same documents you put into Sync Gateway, it’s also got user information stored in it. There’s a bit of discussion about it in this thread that probably explains it better than I can.

Assuming for a second that the backend stuff would all be going through Sync Gateway, using channels as you mentioned definitely seems the way to go. If you were thinking of doing something read-only with the SDKs, well… in theory the same data that’s available to Sync Gateway is all there in the bucket, including what channels a document is in…

@JFlath @jens Ok I read that thread and that makes sense. But since each backend microservice needs to have its own “database” that no other microservices should be able to access, how can I accomplish this? I don’t want to have more than 3 buckets

One of @jens’s comments in the thread I linked is a good starting point:

For example, you can use a docID prefix to distinguish tenants’ docs, and the sync function can then switch on the prefix to apply different logic for different tenants’ docs.

Swap tenants for microservices and you can funnel them into a channel each. Then users can be granted access to a subset (or just one) of those channels. Equally, you could distinguish and filter on a field in the document itself rather than a key prefix if you prefer.

It could be I’m missing something, but this sounds like the kind of thing you want to accomplish.

1 Like