Skip to main content

Infrastructure

Strategies​

You will find hereafter a few options you have in hand to deploy the Datastore alongside of your service.

Straightforward​

Basic deployment of the Datastore as a proxy over MongoDb database. The service is used to add the Event-Source layer between your application and your database.

graph LR; subgraph deployment 1 client(Client) end subgraph deployment 2 ds(["Datastore"]) end subgraph deployment 3 db[(MongoDB)] end client --> |"READ / WRITE"| ds ds --> | 1 node | db

Sidecar​

If your philosophy is to give the responsibility of the data to the own service managing it, a Kubernetes1 sidecar2 is a good option. The Datastore will be collocated with the container of your service, accessible within the same Pod and entities contracts can then be fully controlled by your service business logic.

graph LR; subgraph Kubernetes Pod client("Client <br/>(container)") ds(["Datastore <br/>(container)"]) client:::bold classDef bold font-weight: normal; end subgraph deployment 2 db[(MongoDB)] end client --> | R/W| ds ds --> | 1 node | db

Read / Write MongoDB​

If you are working with a MongoDb Replicaset, you can connect the read operations to the secondary nodes available in the cluster while still having write operations on primary. This advanced configuration is available through environment variables3: MONGO_WRITE_URL and MONGO_READ_URL instead of simpler MONGO_URL.

If you want to play with such a deployment, please have a look to the simple script to deploy a MongoDb Replicaset with Docker easily4.

graph LR; subgraph deployment 1 client(Client) end subgraph deployment 2 ds(["Datastore"]) end subgraph deployment direction LR rs0[("rs0 <br/> (primary)")] rs0 -.- rs1 rs0 -.- rs2 end client --> |"READ / WRITE"| ds ds --> |"WRITE"| rs0 ds --> |"READ"| rs1

Read / Write Datastore​

If your application is requiring a different scaling between read and write you can choose the make different deployments for these 2 use cases. One kind of deployment would then be allocated for read operations, another one for write. In your application, you will have to decide which instance you want to use based on your own use-case.

graph LR; subgraph deployment 1 client(Client) end subgraph deployment 2 read(["Datastore <br/> READ [1..n]"]) write(["Datastore <br/> WRITE [1..m]"]) end subgraph deployment direction LR rs0[("rs0 <br/> (primary)")] rs0 -.- rs1 rs0 -.- rs2 end client --> |"READ"| read client --> |"WRITE"| write write --> |"WRITE"| rs0 read --> |"READ"| rs1
Streaming

With this strategy, you can easily start streaming your data without worrying about scaling of your Datastore's.

  1. https://kubernetes.io↩
  2. https://kubernetes.io/docs/concepts/workloads/pods/#how-pods-manage-multiple-containers↩
  3. https://gitlab.com/getanthill/datastore/-/blob/master/src/config/index.ts#L70↩
  4. https://gitlab.com/getanthill/datastore/-/blob/master/scripts/replicaset.sh#L1↩