just-vibeArchitecture · plan by default
/arch-event-flow
Design event delivery, retries, ordering, and failure handling
Use for asynchronous consistency and delivery design across producers and consumers; backend-jobs implements worker mechanics and backend-idempotency implements single-effect handling for one operation or handler.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select arch-event-flow from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv arch-event-flow, /just-vibe arch-event-flow and /jv:arch-event-flow in Claude. See shortcut setup and context examples.
/just-vibe:arch-event-flow Plan webhook-to-ledger processing with duplicate and reordered events./just-vibe:arch-event-flow Design order events with duplicate delivery and a producer crash after commit./just-vibe:arch-event-flow Assess event flow when broker guarantees are unknown; keep guarantees conditional.What the agent does
- Draw the write/commit/publish/ack sequence across transaction boundaries.
- Place a crash between each pair to find loss and duplicate windows; specify identifiers, schemas, replay identity and effect ownership.
- Define recovery and observability for each failure point.
Inputs
- event source, consumers, delivery guarantees, and failure requirements.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Event ownership, ordering, deduplication, retries, dead letters, and replay.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Plan; event source, consumers, delivery guarantees, and failure requirements.
- Prerequisites
- Readable source, infrastructure/configuration definitions, and any supplied system documentation. Runtime telemetry is optional evidence, never assumed available. Architecture proposals remain plans until implementation is requested.
Expected output
- Event sequence diagram, delivery contract, and a failure-point table covering loss, duplicate, reordering, poison messages and recovery, with validation scenarios.
How the work is checked
- Duplicate and out-of-order deliveries have defined outcomes; a producer crash between database and broker operations is addressed.
When to stop or clarify
- Do not promise exactly-once effects without a concrete consistency mechanism. Avoid choosing infrastructure without throughput and operational constraints.
Handling missing context
- Infer
- Trace current entry points, data owners, deployment units and documented constraints before proposing boundaries.
- Assume
- Prefer extending an existing owner while scale or organizational evidence is absent; mark capacity estimates as assumptions.
- Ask
- Ask for an unresolved consistency, compatibility or ownership requirement only if it changes the design; missing telemetry limits capacity claims, not source mapping.
Technical guidance
- Evidence
- Locate transaction commit, publish, consumer claim, business effect and acknowledgment boundaries.
- Method
- Draw a crash between each durable step; align outbox publication and consumer deduplication with the business transaction where supported.
- Pitfall
- Delivery ordering on one partition does not order all entities, and broker acknowledgment does not prove a business effect committed.
- Check
- Replay a duplicate, deliver versions out of order, and interrupt after the effect before acknowledgment; check one intended effect.
Situational decisions
When database commit and broker publish are separate: Compare a transactional outbox or explicit reconciliation with the actual loss window.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.