-
-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Serverless] Case: monolithic deployment #161
Comments
The drawback here is that the application can't be freely scaled out. When it does, it will have the same subscriptions processing events in parallel, which might create undesired side effects. So, the issue is to ensure that only one subscription instance runs at a given time. |
I noticed a potential issue if the solution is a monolith. If you add a Gateway using RabbitMq as your producer, the subscriptionId will translate into the Queue. |
The gateway will listen to what? If it's a gateway between ESDB and RabbitMQ, you don't need to use the queue name as the subscription id. But in any case, I need to check the queue name convention; it's been a while. It should be possible to override the queue name |
I understand. I will ensure that it is possible to override the exchange name for the gateway producer and have a more fine-grained configuration for the subscription. You can already specify the exchange, but it should be possible to override the queue name. Conventions are good, but there must be a way to override them. Good point, thanks. |
I did some tests with Cloud Run and it's a mess.
Still need to try other services. |
Looking at Porto.actor cluster providers, it seems to be possible to do the elections on services like Azure Container Apps or Amazon Fargate (both EKS and ESC) as there's a way to get the list of members and allow them to communicate. It's still pseudo-serverless as these are just container orchestrators. In sole serverless environments like Lambda of (***)Functions it isn't possible, and it's the same in Google Cloud Run as they also hide the implementation although it supports the KNative API. My conclusion is that using the Connector in a predictable environment (Kubernetes, or a wrapper around it) to run a generic Connector workload, which uses serverless workloads to do the actual job is the only way to do. |
How to make subscriptions work in a serverless world?
Simplest scenario: monolithic deployment
The whole application represents a single bounded context, where commands and queries are combined into a single deployment unit. Such an application would include all the necessary components:
There are two ways to make it work:
The last point also applies to non-serverless scenarios, where we must ensure that read models are updated. It essentially implements the Wait strategy from the docs.
The text was updated successfully, but these errors were encountered: