Skip to main content
Traducción. Autoritativo: ../../slices/track-event.md.

​
Las siete capas

  1. Ruta Runtime POST /v1/core/track — auth (api key o write key), envelope Zod, rate limit en Upstash, permiso core.events.write. SIN lógica de negocio. Devuelve 202 {event_id} en <100 ms p95.
  2. Publicación en cola — QueuePort.publish('core.ingest', envelope\{job_id, tenant_id, correlation_id, data}). Adaptador vinculado en el composition root del módulo core (Vercel Queues en F1).
  3. Procesador (worker) — compuerta de idempotencia (core.processed_jobs por job_id; idempotency_key de tracked_events como segunda valla). Pasos en un solo flujo lógico: resolución y upsert de identidad → append en tracked_events (particionada; disciplina del predicado occurred_at) → evaluación incremental de segmentos (diff → entered/exited) → matching del motor de reglas (caché de reglas compiladas por tenant).
  4. Escrituras de dominio — los efectos se ejecutan vía los servicios de dominio de loyalty (por ejemplo, award_points → transacción del libro + lote + proyección de saldo en la MISMA transacción).
  5. Outbox + auditoría — todo cambio de estado emite eventos y filas de auditoría con correlation_id y causation_id (patrón de ADR-017).
  6. Consumidores — despacho de notificaciones (resolveChannels → jobs por canal y carril), webhooks salientes (HMAC), invalidación de caché, medición.
  7. Tests y presupuestos — unitarios: resolveChannels, evaluación del DSL, deduplicación de reglas; integración: pipeline completo con replay de job duplicado (debe ser no-op); carga: k6 con track p95 <100 ms, visibilidad del efecto end to end <5 s p95 en certificación. Todos los presupuestos son ítems del DoD.

​
Qué copian los agentes de acá

Forma del fast-ack · ubicación de la compuerta de processed_jobs · una transacción con escritura + outbox + auditoría · propagación de la correlación · disciplina de la clave de partición · selección de carril para las notificaciones.