Summary
Migrate from direct DB audit inserts to event-sourced architecture, enabling audit replay, time-travel debugging, and event-driven projections.
Current State
- Audit entries written directly to PostgreSQL
audit_log table
- No replay capability — if projection is wrong, must fix manually
- Tightly coupled to DB schema
Proposed Architecture
┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ ┌─────────────┐
│ Any Action │────►│ Dapr │────►│ Audit │────►│ Event Store │
│ │ │ PubSub │ │ Consumer │ │ (append-only)
│ │ │ "audit" │ │ │ │ │
└─────────────┘ └─────────────┘ └─────────────────┘ └─────────────┘
│
▼
┌─────────────────┐
│ Projections │
│ (rebuild on │
│ demand) │
└─────────────────┘
Implementation Steps
Acceptance Criteria
Technical Notes
- Start simple: PostgreSQL as event store, single projection
- Consider EventStoreDB or Kafka for production scale
- Event versioning critical for schema evolution
- Idempotency keys prevent duplicate processing
Labels
enhancement learning event-driven architecture phase-v2
📚 Learning Goal: Event Sourcing & CQRS patterns
Summary
Migrate from direct DB audit inserts to event-sourced architecture, enabling audit replay, time-travel debugging, and event-driven projections.
Current State
audit_logtableProposed Architecture
Implementation Steps
audit-eventsDapr PubSub topiclog_action()to publish events instead of direct DB insertAcceptance Criteria
Technical Notes
Labels
enhancementlearningevent-drivenarchitecturephase-v2📚 Learning Goal: Event Sourcing & CQRS patterns