El runtime de Dome resuelve una pregunta aparentemente simple: «¿puede este actor leer este dato con este scope, ahora mismo?». La respuesta tiene que llegar en menos de 2ms p95 y dejar trazabilidad. Spoiler: las dos cosas son compatibles.
El layout de una celda
Una celda en Dome es una unidad de datos con tres componentes:
- Storage · los bytes del dato propiamente dichos. Pueden vivir en S3, Iceberg, Postgres, Snowflake.
- Policy bundle · las políticas vigentes para esa celda, compiladas a un decision tree.
- Audit log local · append-only, mismo storage que el dato.
La separación importa: el policy bundle se actualiza cuando cambia la política, no cuando cambia el dato. La celda no recompila políticas en runtime.
Resolución de scope
Cuando llega una request, pasa por:
agent → mesh → cell.intake → policy.eval → storage.read → cell.emit_log → response
↑ 0.4–1.2ms p95 aquí
El cuello de botella es la evaluación. La hacemos rápida con tres decisiones:
- Decision tree precompilado, no AST de YAML interpretado.
- Cache de decisión por
(actor, scope, cell_id)con TTL de 60s. Cache hit rate típico: 92%. - Evaluación en-celda, sin RPC a un servicio externo de PDP.
Federación
Si tu organización tiene celdas en EU-West-1, EU-Central-1 y US-East-1, el agente puede pedir datos de las tres regiones en una sola sesión. La política de cada celda se evalúa localmente; el resultado se federa al final.
Detalles operativos en el whitepaper Modelo de Celda.