Execution Model

Cómo vive y se activa el trabajo

Execution Model examina cuándo, dónde, durante cuánto tiempo y bajo qué trigger y lifecycle ejecuta trabajo el sistema. Describe activación, avance, terminación, continuidad y relación con estado. No se reduce a threads, productos de compute ni síncrono frente a asíncrono.

Es una dimensión de architecture-decision-axes. Puede combinar request handling, consumidores, workers, tareas programadas, batch y procesamiento continuo. Las combinaciones que siguen ayudan a examinar decisiones; no son una taxonomía universal ni opciones mutuamente excluyentes.

La literatura arquitectónica distingue estructuras de módulos, relaciones durante ejecución y asignación al entorno. Esa separación ayuda a no deducir el comportamiento runtime desde carpetas o artifacts. El uso de este eje es una síntesis editorial para preguntar por la vida del trabajo. SEI, System-of-Systems Viewpoint, sección 6.5.

Communication y espera son preguntas distintas

communication examina cómo se intercambia información. HTTP puede transportar un request que activa procesamiento; un broker puede entregar un mensaje a un consumidor. El protocolo o intermediario no define todos los triggers ni el lifecycle del trabajo.

Síncrono y asíncrono describen aspectos de interacción o espera. Un servicio de larga duración puede realizar operaciones async; un batch puede efectuar llamadas síncronas. Orders puede responder al request después de aceptar un job cuya finalización ocurrirá luego.

Tampoco async equivale a background worker: una operación no bloqueante puede completarse dentro del mismo lifecycle del request. Hay que aclarar si la respuesta representa aceptación, resultado final o error, y quién conserva la obligación de completar lo pendiente.

Threading model y concurrency model precisan realización y simultaneidad. Interactúan con el eje, pero elegir un pool de threads no responde por sí solo cuándo se activa un job, cómo termina o cómo se recupera.

Request-driven execution

En una realización request-driven, llega una solicitud, se asigna capacidad de ejecución, se procesa y se responde. «Asignar» no exige crear un nuevo thread: el runtime puede usar un event loop, pool u otra organización.

Orders API puede validar Place Order y devolver un resultado o una aceptación identificable. La demanda visible del caller ofrece una relación directa con trabajo iniciado. También introduce presupuesto de latencia, picos de consumo y dependencia del caller respecto de la respuesta.

Si el request dispara trabajo diferido, debe definirse la frontera: cuándo la aceptación es durable, qué ocurre si la conexión se pierde y cómo consultar progreso. Mantener la conexión abierta no es la única forma de conservar responsabilidad.

admission-control y load-shedding ayudan a examinar qué trabajo se acepta o rechaza cuando falta capacidad. El artículo de ejecución no redefine sus políticas ni supone que una API soporte cualquier carga por funcionar bajo tráfico normal.

Message-driven y background workers

Un consumidor puede activarse cuando llega un mensaje o consultar trabajo cuando está listo. Enterprise Integration Patterns distingue entrega automática a un Event-Driven Consumer y solicitud explícita en Polling Consumer. Son formas de recepción dentro de un modelo, no el eje completo. Event-Driven Consumer, Polling Consumer.

Un background worker realiza trabajo fuera del lifecycle inmediato del caller. Puede consumir, procesar, persistir resultado y confirmar recepción. PaymentSettlement podría ejecutar liquidaciones diferidas; un worker también puede leer tareas de otra fuente sin un broker.

El buffering puede desacoplar tiempos y suavizar demanda, a cambio de backlog, espera y visibilidad de progreso. queue-management mantiene el análisis de trabajo pendiente. backpressure examina cómo se comunica o limita presión según el mecanismo; una cola no garantiza capacidad sostenible.

Recibir un mensaje no equivale a completar su efecto. Con at-least-once pueden existir duplicados; idempotency protege un efecto bajo su contrato y retry requiere condiciones seguras. La garantía concreta depende de persistencia, confirmación y recuperación; «es un worker» no la define.

Message-driven tampoco caracteriza automáticamente todo el sistema como event-driven-architecture. Puede consumir comandos de un coordinador explícito y coexistir con requests o batch. EDA explica la centralidad de hechos e interacción; no prescribe un único trigger o lifecycle para sus consumidores.

Scheduled no equivale a Batch

Scheduled execution utiliza tiempo o calendario como trigger. InventoryReconciliation puede lanzarse cada noche; una limpieza puede ejecutarse periódicamente. Importa qué instante se interpreta, qué zona horaria aplica y cómo tratar cambios del reloj o transiciones del calendario.

Una ejecución programada puede perderse, duplicarse o solaparse con la anterior. Google SRE muestra que distintos jobs admiten de forma diferente lanzamientos omitidos y repetidos; la política necesita conocer sus efectos. Un scheduler instalado no prueba ejecución exactamente una vez. Distributed Periodic Scheduling.

Batch execution trabaja sobre un dataset o workset finito y tiene un criterio de finalización. Puede iniciarse por horario, request administrativo o llegada de información. Procesar una conciliación sobre un corte elegido es batch, aunque el operador la lance manualmente.

A la inversa, un trigger periódico puede revisar pendientes y activar tareas sin definir un único batch finito. El trigger y la forma del trabajo son dimensiones relacionadas que deben describirse por separado.

En Commerce, recuperar una conciliación fallida requiere conocer su conjunto, avances y efectos confirmados. Empezar de nuevo puede ser válido o duplicar modificaciones; repetir el lanzamiento y recuperar la intención no son necesariamente la misma operación.

Stream y procesamiento continuo

El procesamiento continuo trabaja sobre entrada que puede seguir llegando sin un final global conocido. Un flujo de cambios de pedidos puede mantener estadísticas o detectar condiciones mientras el sistema opera.

Un batch sobre mensajes acumulados sigue teniendo un conjunto y finalización delimitados; usar mensajes no lo convierte en procesamiento continuo. Un procesador continuo puede, a su vez, producir resultados por ventanas o cortes sin declarar que toda la entrada terminó.

Akidau y colaboradores examinan datos no acotados, desorden y compromisos entre corrección, latencia y costo. Esa literatura sustenta la necesidad de definir cómo se interpretan resultados que pueden revisarse, sin hacer del producto Dataflow la definición del eje. The Dataflow Model, 2015.

Aquí basta preguntar qué progreso es observable y qué resultado significa completo o actualizado. Checkpoints, recuperación y criterios temporales dependen del contrato; no se desarrolla un tutorial de streaming ni se promete semántica universal.

Duración del proceso y duración del trabajo

Long-lived execution mantiene un servicio o proceso activo para atender muchas unidades de trabajo. Short-lived execution inicia para un trabajo acotado y termina. Estas duraciones no equivalen a request frente a batch.

Realización	Trabajo	Lifecycle ilustrativo
Orders API	Requests individuales.	Proceso de larga duración.
PaymentSettlement	Tareas diferidas.	Worker continuo o por job.
InventoryReconciliation	Workset finito.	Ejecución hasta completar.
Shipping consumer	Mensajes sucesivos.	Consumidor persistente o activado.

Una función cloud puede ilustrar ejecución bajo demanda, sin definir toda la categoría. serverless-architecture combina delegación de infraestructura, ejecución y capacidad; no es sinónimo de Execution Model ni sustituye la descripción del trigger. Su realización puede incluir requests, consumidores, jobs o workflows gestionados con lifecycles distintos.

La ubicación puede ser proceso compartido, proceso separado, nodo, device, edge o entorno cloud. Es relevante si condiciona recursos y recuperación. No determina por sí sola duración ni forma de trabajo.

Stateful y stateless: no borrar el estado

Stateless execution suele significar que el estado requerido entre interacciones no depende de una instancia de proceso particular. El sistema puede conservar estado en una base, servicio externo o cache bajo obligaciones explícitas. Stateless no significa ausencia de estado ni efectos.

Una Orders API puede procesar otro request desde una instancia distinta y conservar pedidos persistentes. Una cache local puede ser una optimización, siempre que perderla no viole el contrato que se promete. La etiqueta no demuestra esas condiciones.

Stateful execution puede mantener sesión, estado de partición o progreso local que deba recuperarse o trasladarse. Deben aclararse autoridad, persistencia y consecuencias de reemplazar la instancia. data-ownership pregunta quién define el estado; este eje pregunta cómo su ubicación y duración condicionan ejecución.

Deployment, perfiles y Tenancy

deployment pregunta qué se instala junto. Un servicio desplegado como unidad puede alojar handlers HTTP, un background consumer y una tarea programada: una unidad, varios modelos. El mismo tipo de worker también puede existir en varias unidades desplegables.

monolith y modular-monolith no exigen solo requests locales. microservices, service-based-architecture y service-oriented-architecture pueden combinar APIs, consumidores y jobs. Un architecture-profile conserva un paquete de decisiones sin especificar completamente la ejecución.

tenancy añade contexto: un request de Tenant A, un mensaje diferido y su job deben preservar el ámbito permitido de datos, configuración y consumo. Cambiar de thread o terminar el request no concede permiso para olvidar ese contexto.

Commerce y consecuencias cruzadas

La variante ilustrativa reúne Orders, Payments, Inventory y Shipping en una aplicación. Orders API es request-driven; PaymentSettlement usa trabajo diferido; InventoryReconciliation es batch programado; Shipping consume solicitudes. Comparten deployment y pueden necesitar pools o límites internos de isolation.

Otra variante separa los workers sin cambiar necesariamente sus triggers. coordination mantiene la política de resultados conjuntos: ejecución explica quién está activo y cómo progresa el trabajo, no quién puede declarar un pedido confirmado.

operability debe distinguir health de un proceso, finalización de un job y atraso de un consumidor. cost-efficiency incluye capacidad idle de procesos activos y arranque, pricing, forma de carga y operación de ejecuciones bajo demanda. On-demand no significa siempre más barato. portability pregunta qué supuestos de runtime deben conservarse al cambiar de entorno.

Los modelos también cambian cómo se incrementa capacidad: concurrencia de requests, consumidores o particiones de un workset no son la misma decisión. scaling examina unidad ampliable, recursos y límites; el lifecycle del trabajo condiciona esa elección sin definirla por completo.

Revisar aceptación, efecto, progreso y recuperación de cada actividad de Commerce. Esa evidencia ofrece una descripción de ejecución más útil que contar threads o nombrar una plataforma.