Case Study
Forge — LLM Batch & Realtime Orchestration
Provider-agnostic AI job infrastructure for batch and realtime workloads across OpenAI and Anthropic.
Built a crash-safe worker system where two Node daemons coordinate through Postgres alone — no queue, no shared process — so jobs survive crashes and keep moving.
Discuss a similar projectCase study by Aggelos Konstantilieris
Forge — LLM Batch & Realtime Orchestration
Two cooperating Node daemons coordinate LLM batch and realtime jobs through Postgres only. Most AI apps stop at calling an API; Forge handles the operational layer — batching, provider routing, leases, retries, crash recovery, quota recovery, validation, notifications, and observability.
At a glance
By the numbers
- jobs per replica
- ~40/s
- ≈3.4M per day
- lower token cost
- ~50%
- provider Batch APIs
- LLM providers
- 2
- OpenAI + Anthropic
- worker loops
- 9
- two cooperating daemons
- queue services
- 0
- Postgres-only coordination
What we were solving
Context & problem
LLM workloads need both batch and realtime execution, provider flexibility, retry safety, cost awareness, validation, and operational visibility. A queue-based architecture adds infrastructure and coordination complexity.
Forge explores a Postgres-centered architecture where workers coordinate through the database alone — no queue, no IPC, no shared worker processes.
How we approached it
Solution
Anvil (the builder) claims eligible pending rows and shapes them into provider-compatible batches. Hammer (the executor) advances those batches through worker loops that submit, poll, collect, execute realtime jobs, recover stale leases, archive cooled batches, stamp updates, recover quota, and send notifications.
OpenAI and Anthropic ship through provider ports; the core execution model stays provider-agnostic. The two daemons share only Postgres — all coordination lives in the database, with no separate queue or message bus.
Impact
Outcomes
- - Batch and realtime LLM execution paths in one architecture.
- - Worker coordination through Postgres without a separate queue service.
- - Lease expiry for crash recovery and stale worker reclamation.
- - OpenAI and Anthropic via provider ports.
- - Provider outputs revalidated against processor response schemas before success.
- - Operator-facing health, metrics, archive, credentials, costs, architecture surfaces.
- - Horizontal scaling: every daemon and worker is safe to run as multiple copies.
Behind the scenes
Tech & delivery
Stack
- Node.js
- TypeScript
- PostgreSQL
- OpenAI Batch API
- Anthropic Batch API
- NestJS
- Prometheus
- React + Vite
Challenges
- Coordinating two daemons and nine worker loops through Postgres alone, instead of running a separate queue service.
- Keeping side effects (tag updates, notifications) consistent with each job's state change, even across crashes.
- Validating provider outputs fail-closed against processor response schemas before accepting success.
- Designing provider ports so OpenAI and Anthropic batch semantics stay behind one execution model.
How I worked
- Lease-based crash recovery and idempotent claiming make every daemon and worker safe to scale horizontally.
- Prometheus metrics, health endpoints, and a local operator viewer expose jobs, batches, costs, and live architecture.
- A quota recovery control loop pauses exhausted provider keys and probes them back into service.
How it holds together
Technical highlights
Postgres-only coordination
No queue, IPC, or shared process. All coordination lives in the database.
Provider-agnostic batch execution
OpenAI and Anthropic ship in-tree through a BatchProviderPort registry.
Crash-safe workers
Stalled jobs are detected and re-run automatically; every worker is safe to run more than once.
Reliable side effects
Tag updates and notifications are recorded together with each job's state change, so nothing is lost on a crash.
Prompt Platform v2
Processor prompts, schemas, output policies, tags, validation, preview, promotion surfaces.
Fail-closed validation
Provider success lines revalidated against response schemas before acceptance.
Quota recovery loop
Provider keys pause on quota exhaustion and recover via no-spend probe logic.
Operator UI
Local viewer: jobs, batches, archive, processors, credentials, costs, brand, live architecture.
More work
Related case studies
Matcha — AI Booking Platform
Live booking system for appointments and classes: an AI assistant answers customer messages on WhatsApp and books once they confirm, a hosted booking page takes direct bookings, and one calendar keeps the whole team in sync.
View case studyOmni AI Integration Architecture
AI-augmented maritime CRM architecture for classification, entity extraction, prompt-action workflows, and operational automation.
View case studyApollon CRM
Full-stack CRM for pet boarding teams with room scheduling, client records, booking management, and financial reporting.
View case study