Documentation Index
Fetch the complete documentation index at: https://docs.litejoin.io/llms.txt
Use this file to discover all available pages before exploring further.
Deployment Guide
LiteJoin is a single binary with no external dependencies. This makes deployment simple, but there are operational considerations for production use.Resource Planning
CPU
LiteJoin is lightweight. A 2-vCPU machine handles most workloads. CPU usage scales with:- Number of sources (each poll cycle parses JSON, diffs, and writes)
- Join complexity (each write triggers join re-evaluation)
- Window evaluation frequency
Memory
Default memory usage is ~50–100 MB. SQLite’s page cache is the main consumer. If tiered storage is enabled with DuckDB, allocate additional memory (default DuckDB limit: 256 MB).Disk
Disk usage depends on:- Shard count × retention duration × ingest rate
- Each shard is a separate SQLite database file
- WAL files can temporarily double the on-disk size during heavy writes
Network
API source polling generates outbound HTTP requests. Calculate your request budget:Monitoring
Health Check
Log Levels
LiteJoin logs to stdout. Key patterns to monitor:| Pattern | Level | Meaning |
|---|---|---|
api-source X: poll failed (N/max) | WARN | Transient source failure |
api-source X: ERROR N consecutive failures | ERROR | Source degraded |
dlq: enqueued result for sink | INFO | Delivery failure captured |
dlq: entry exceeded max retries | ERROR | Permanent delivery failure |
joiner: FAILED sink send | WARN/ERROR | Sink unavailable |
Pipeline Monitoring
LiteJoin logs pipeline queue depths periodically to help diagnose bottlenecks:Graceful Shutdown
LiteJoin handlesSIGTERM and SIGINT gracefully:
- Sources stop polling / consuming
- In-flight messages are flushed to storage
- Pending DLQ retries complete
- Sink connections are closed
- SQLite databases are checkpointed and closed