Siglo features a decoupled storage architecture: the workflow runtime operates cleanly in memory, while state persistence, distributed caching, audit trails, and idempotency claims are delegated to pluggable StorageAdapter implementations.
1. The StorageAdapter Interface
useStorage(adapter):
2. Production Ecosystem Adapters
@siglo/postgres
ACID-compliant state persistence, durable checkpoint storage, audit event log tables, and transactional idempotency locking.
@siglo/redis
Low-latency state caching, distributed TTL step caching, atomic idempotency claim sets, and distributed redlock mutexes.
Event & Transport Adapters
@siglo/express: HTTP route handler adapter.@siglo/fastify: High-performance Fastify route handler adapter.@siglo/hono: Web Standards (Request/Response) adapter (requires Node runtime APIs such asnode:async_hooksandnode:netor polyfilled Node compatibility mode).@siglo/kafka: High-throughput Kafka consumer partition batch processor.@siglo/bullmq: Resilient Redis background queue job runner.@siglo/sqs: AWS SQS batch consumer with partial failure reporting.
3. Multi-Tenancy & Namespaces
Every checkpoint, cache key, and event stream supports namespace scoping:Minimal Example
Failure Example: Handling Storage Adapter Outages
ConfiguresetErrorMode() ('best-effort' | 'warn' | 'strict') to define behavior when storage adapters encounter errors:
Testing Example
UsingInMemoryStorageFake from @siglo/testing:
Operational Caveats
- Table Schema Migration: When deploying
@siglo/postgres, executeensureTables()during database migrations or deployment pipelines, not on individual application instance boot. - TTL Cleanups: Configure a cron job or background worker to call
cleanExpiredCheckpoints()daily to maintain optimal database query speeds. - Optimistic Locking: Storage adapters implement optimistic concurrency control (OCC) to prevent conflicting concurrent executions on the same stack identifier.
