wiki/tasks/flightradar24/docs/COMPOSE_SKELETON.md

FR24 ingest compose skeleton

Goals

• PostgreSQL + PostGIS as the single database
• separate ingest placeholder service
• healthcheck/status scaffolding
• predictable volume layout
• environment-driven configuration

Proposed runtime layout

• compose/ — Docker Compose manifests and env examples
• db/postgres/ — persistent PostgreSQL data
• db/init/ — bootstrap SQL for extensions and initial schema
• ingest/ — capture/preprocess implementation lives here later
• logs/ingest/ — service logs
• logs/status/ — heartbeat/status artifacts
• backup/ — pg_dump and restore artifacts

Environment variables

• POSTGRES_DB
• POSTGRES_USER
• POSTGRES_PASSWORD
• POSTGRES_PUBLISHED_PORT
• RAW_RETENTION_DAYS
• OVERLAP_MINUTES
• CAPTURE_SOURCE
• TZ
• APP_ENV

Status scaffolding

The current skeleton includes a minimal status container that writes a heartbeat file. This is only a placeholder and should be replaced or extended by a real monitoring endpoint later.

Open questions

• whether capture and preprocess should become separate services immediately
• whether API/viewer belongs in the first compose cut or later
• whether a dedicated monitoring container is needed before hardware verification