Stateful stores

Cloudstate depends on databases to provide all durable entity types, such as event sourcing. Multiple different database backends are supported. The configuration for these backends is deployed independently from the services that consume them. Developers don’t need to concern themselves with where or how a database is deployed, nor how to connect and authenticate with it, when they deploy their services. This is done using the StatefulStore resource. Here is an example StatefulStore resource for a PostgreSQL store:

apiVersion: cloudstate.io/v1alpha1
kind: StatefulStore
metadata:
  name: my-postgres-store
spec:
  type: Postgres (1)
  deployment: Unmanaged (2)
  config: (3)
    service: postgresql.default.svc.cluster.local
    credentialsFromSecret:
      name: postgres-credentials
1 type: The type of the store. Currently supported stores are Cassandra, Postgres and InMemory.
2 deployment: How the store is deployed. Valid values depend on the store type. Unmanaged means that the Cloudstate operator does not manage the deployment of the stateful store, currently, all stores only support unmanaged deployment. In the future, support may be added to allow Cloudstate to deploy the database itself, this will typically rely on a third party cloud database management service.
3 config: Configuration specific to the type of database and it’s mode of deployment. The available configuration options are detailed in the store specific documentation.

Using a stateful store

A stateful service can use a stateful store by selecting it using the datastore field of the stateful service spec. For example, the following would configure the shopping-cart stateful service to use the my-postgres-store configured above:

apiVersion: cloudstate.io/v1alpha1
kind: StatefulService
metadata:
  name: shopping-cart
spec:
  datastore:
    name: my-postgres-store
  containers:
  - image: my-docker-hub-username/shopping-cart:latest