<p>I am re-designing a dotnet backend api using the CQRS approach.  This question is about how to handle the Query side in the context of a Kubernetes deployment.</p>
<p>I am thinking of using MongoDb as the Query Database.  The app is dotnet webapi app.  So what would be the best approach:</p>
<ol>
<li><p>Create a sidecar Pod which containerizes the dotnet app AND the MongoDb together in one pod.  Scale as needed.</p>
</li>
<li><p>Containerize the MongoDb in its own pod and deploy one MongoDb pod PER REGION.  And then have the dotnet containers use the MongoDb pod within its own region.  Scale the MongoDb by region.  And the dotnet pod as needed within and between Regions.</p>
</li>
<li><p>Some other approach I haven't thought of</p>
</li>
</ol>

brando
<p>It has been almost 2 years since I posted this question.  Now with 20-20 hindsight I thought I would post my solution.  I ended up simply provisioning an Azure Cosmos Db in the region where my cluster lives, and hitting the Cosmos Db for all my query-side requirements.</p>
<p>(My cluster already lives in the Azure Cloud)</p>
<p>I maintain one Postges Db in my original cluster for my write-side requirements.  And my app scales nicely in the cluster.</p>
<p>I have not yet needed to deploy clusters to new regions.  When that happens, I will provision a replica of the Cosmos Db to that additional region or regions.  But still just one postgres db for write-side requirements.  Not going to bother to try to maintain/sync replicas of the postgres db.</p>
<p>Additional insight #1.  By provisioning the the Cosmos Db separately from my cluster (but in the same region), I am taking the load off of my cluster nodes.  In effect, the Cosmos Db has its own dedicated compute resources.  And backup etc.</p>
<p>Additional insight #2.  It is obvious now but wasnt back then, that tightly coupling a document db (such as MongoDb) to a particular pod is...a bonkers bad idea.  Imagine horizontally scaling your app and with each new instance of your app you would instantiate a new document db.  You would quickly bloat up your nodes and crash your cluster.  One read-side document db per cluster is an efficient and easy way to roll.</p>
<p>Additional insight #3. The read side of any CQRS can get a nice jolt of adrenaline with the help of an in-memory cache like Redis.  You can first see if some data is available in the cache before you hit the docuement db.  I use this approach for data such as for a checkout cart, where I will leave data in the cache for 24 hours but then let it expire.  You could conceivably use redis for all your read-side requirements, but memory could quickly become bloated. So the idea here is consider deploying an in-memory cache on your cluster -- only one instance of the cache -- and have all your apps hit it for low-latency/high-availability, but do not use the cache as a replacemet for the document db.</p>
