ApexArchitect (Hardest)platform-eventsevent-drivenldv
Design high-volume Platform Event fan-out for 2M daily order status changes
Real World Scenario
Warehouse, analytics, and partner systems subscribe to Order_Status_Changed__e. Publish rate spikes to 500 events/sec during peak causing subscriber lag and replay gaps.
Expected Answer
• High-volume Platform Event for throughput; standard event for durability-critical paths
• Minimal payload: OrderId, newStatus, changedAt—subscribers query fresh data
• Multiple subscriber types: one Apex trigger per concern not monolithic handler
• Idempotent subscriber processing with processed_event_id dedup table
• Replay ID persisted externally for subscriber recovery after downtime
• Monitor EventBusSubscriber metrics and lag in Event Monitoring
• Complementary CDC when subscribers need full field-level change detail
Follow-Up Questions & Answers
Click to expand — each follow-up includes a direct, interview-ready answer
Direct answer: High-volume Platform Event for throughput; standard event for durability-critical paths Also consider: Minimal payload: OrderId, newStatus, changedAt—subscribers query fresh data In practice: Multiple subscriber types: one Apex trigger per concern not monolithic handler Document the decision in an ADR and align with enterprise standards.
Architect Perspective
High-volume events trade durability for scale—design subscribers for at-least-once duplicate delivery.