Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Serverless] Case: monolithic deployment

Abierto
  • ¿Algo no está bien?
#161 7 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 7 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
15/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
csharp
Área
backend, distributed-systems

Línea de trabajo

Start with the linked Wait strategy in the read-model concept docs and compare it with the three approaches described here. The issue does not name code files or tests; first identify the subscription and command API entry points that implement read-model waiting. Done means choosing and implementing a serverless approach that reliably waits for all produced events to be processed, with behavior and tests defined.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement serverless subscriptions

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:

  • Command services
  • Command APIs
  • Query services
  • Read model subscriptions
  • Gateways

There are two ways to make it work:

  1. Just do nothing. Expect the function/container timeout to be enough for all the subscriptions to handle newly produced events. It would work in many cases, but there's no resilience against external infrastructure failures for event handler targets.
  2. Ensure the command is handled in an asynchronous unit of work. The command service would do its thing, as usual; there's no change required. Subscriptions would expose an internal HTTP API to report the last processed event position. A new function is needed to poll the API from inside the service, simulating traffic until all the subscriptions get beyond the position of the last produced event. It will prevent the function from being shut down (in theory).
  3. Ensure the command is handled in a synchronous unit of work. The command API will block until all subscriptions handle all the produced events in the application. It requires some method of internal asynchronous communication. Subscriptions will produce internal messages with the latest processed event position. The command API can observe these messages, so it can ensure that all the new events are handled. After that's confirmed, the command API returns the response as usual.

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.

Lenguaje dominante
C#
Estrellas
512
Forks
99
Merge medio
5 d 6 h
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Eventuous/eventuous

Todos los issues de Eventuous/eventuous

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.