Event-Driven Architecture Vocabulary

Event: a record of something that occurred — past tense, immutable. "OrderPlaced", "UserRegistered", "PaymentFailed". The emitter broadcasts to all interested parties without knowing who they are. Multiple consumers can react independently. Command: an instruction targeting a specific service — "ProcessPayment", "SendEmail", "UpdateInventory". Implies one designated handler. Typically expects acknowledgment. Query: request for data — "GetOrderById". Expects a response. EDA coupling benefits: Temporal decoupling: producer and consumer don't need to be running simultaneously (broker buffers). Interface decoupling: producer doesn't import or depend on consumer code. Deployment decoupling: services can be deployed independently. Scaling decoupling: consumers scale independently based on their own throughput needs. Naming conventions: events use past tense noun-verb: OrderPlaced, ShipmentDispatched, PaymentDeclined. Commands use imperative: PlaceOrder, ShipOrder, DeclinePayment. Message envelope vocabulary: Topic/Queue: the address to which messages are sent. Partition key: ensures messages for the same entity go to the same partition (ordering). Message ID: unique identifier for deduplication. Correlation ID: links related messages in a workflow. Timestamp: when the event occurred (not when it was published). In conversation: 'When OrderService calls InventoryService directly, it has a compile-time dependency on it. With events, those services have never heard of each other. That's the decoupling we're after.'

Dead letter queue (DLQ): a special destination for messages that cannot be successfully processed. Prevents one bad message from blocking an entire queue indefinitely. Causes of DLQ routing: Max retries exceeded: consumer failed N times (configurable). Poison pill: a malformed message that always causes a processing exception (e.g., invalid JSON, missing required field). Message TTL exceeded: message sat in the queue longer than its time-to-live. Consumer rejection: consumer explicitly nack'd the message without requeue. Delivery guarantee vocabulary: At-most-once: messages may be lost but never duplicated. Consumer acknowledges before processing. Simplest to implement, lowest overhead. Use for non-critical metrics. At-least-once: messages will be delivered, potentially multiple times. Consumer acknowledges after successful processing. Producer retries if no ack received. Consumers must be idempotent (safe to process duplicate messages). Exactly-once: each message delivered and processed exactly once. Requires coordination (Kafka transactions, idempotent consumers with deduplication). Highest cost/complexity. Idempotency strategies: Natural idempotency: processing the same "set name=John" twice has the same outcome. Idempotency key: consumer tracks processed message IDs and skips duplicates. Conditional updates: update only if version/timestamp matches. In conversation: 'Monitor your DLQ. A spike in DLQ messages is often your first indicator of a downstream service degradation or a schema mismatch after a deployment.'

Schema registry: a versioned catalog of message schemas that producers and consumers use to serialize/deserialize messages. Without it: the schema is embedded in producer code and consumer code independently — any mismatch causes failures. Confluent Schema Registry: stores Avro, Protobuf, or JSON Schema definitions. Each schema version has an ID. Producers include the schema ID in each message. Consumers fetch the schema by ID to deserialize. Compatibility modes: BACKWARD: new schema can read messages written with old schema. Consumers can upgrade first. (Safe default: add optional fields.) FORWARD: old schema can read messages written with new schema. Producers can upgrade first. FULL: both backward and forward compatible. NONE: no compatibility checking — dangerous. Schema format vocabulary: Avro: binary format with schema embedded. Compact, popular with Kafka. Schema defined in JSON. Protobuf: Google's binary format. Field numbers for backward compatibility. Excellent for gRPC (see grpc-protobuf exercises). JSON Schema: human-readable, widely understood. Larger payload size. CloudEvents standard: a CNCF specification for event envelopes — standardizes metadata fields (id, source, type, time, datacontenttype) while leaving the data payload to the application. Enables tooling interoperability across brokers. In conversation: 'Every team that owns a topic should register its schema on day one. Enforcing compatibility at the registry level stops breaking changes before they break production.'

Choreography: services react to events without a central coordinator. Each service knows only its own trigger events and what it emits. Advantages: loose coupling, services are independently deployable and scalable. Disadvantages: the overall workflow is implicit — it exists only as a pattern of event flows. Hard to monitor, debug, or change. The "where is my order?" question requires correlating events across multiple topics. Orchestration: a central coordinator (saga orchestrator, Step Functions state machine, Temporal workflow) sends commands and waits for responses. Advantages: explicit, visible workflow; easy to monitor progress; simple to add compensation steps (rollback). Disadvantages: orchestrator knows about all services (coupling); single point of failure if not resilient. Saga pattern vocabulary: Saga: a long-running transaction composed of local transactions with compensating actions for rollback. Choreography saga: compensating events emitted by each service. Orchestration saga: coordinator sends compensation commands. Step Functions / Temporal vocabulary: Workflow: the definition of an orchestrated business process. Activity: an individual unit of work (an API call, a database update). Compensation: the undo action for a completed step. In conversation: 'Start with choreography for simplicity. Add an event-correlation service or upgrade to orchestration when debugging "where is my order?" becomes a weekly pain.'

Message queue (SQS, RabbitMQ): competitive consumption model. Message is received by one consumer from the competing group. After acknowledgment, the message is deleted. Use for work distribution: N workers processing a task queue, each task done exactly once. No replay, no history. Message log/stream (Kafka, Kinesis, Azure Event Hubs): publish-subscribe with durable retention. Multiple consumer groups can read the same topic independently, each maintaining its own offset. Messages are retained for configured duration (hours to forever). New consumers can replay from the beginning. Use for event-driven integration, audit logs, stream processing, data pipelines. Broker comparison: Kafka: distributed log, partitioned, retained, consumer groups, replay, very high throughput. Operational complexity. SQS: managed queue, at-least-once, visibility timeout, DLQ, FIFO option. Simple. SNS: pub/sub fanout (broadcast to multiple SQS queues, Lambda, HTTP endpoints). Not a queue — no retention. RabbitMQ: traditional AMQP broker, flexible routing (exchanges, bindings), plugin ecosystem. EventBridge: AWS managed event bus, content-based routing rules, schema registry, cross-account. Use when source is AWS services or SaaS integrations. In conversation: 'If you need replay — to replay events for a new service, fix a consumer bug, or audit past behavior — you need Kafka or a log-based system. A queue can't give you that.'

A circuit breaker monitors the health of dependent services. When it detects excessive failures (e.g., slow response times or errors) from downstream consumers, it 'opens' – temporarily stopping requests to those consumers to prevent overload and allow them time to recover. This is a crucial pattern for resilience in event-driven systems where dependencies can introduce points of failure.

The key issue is decoupling. Directly consuming events from a producer (PaymentService) without a buffer or intermediary can lead to problems if the LoggingService becomes overwhelmed or temporarily unavailable. Using a message queue (like Kafka or RabbitMQ) provides this crucial separation – ensuring that events are reliably delivered and processed, even if the consumer experiences temporary issues.

Emily's approach – where each service independently consumes and reacts to events – represents choreography. This pattern relies on loosely coupled services communicating through events, offering flexibility and scalability. It contrasts with orchestration (where a central controller manages the flow) and direct API calls (which introduce tight coupling).

Kafka's core design – its distributed log architecture – inherently allows for event replay. Because Kafka retains events on disk for a configurable period (configurable retention policies), consumers can consume the same event multiple times to recover from failures or perform historical analysis. This is a key differentiator compared to message queues like SQS which delete messages after consumption.

In an event-driven architecture, events are typically routed across a network. Network latency is a common bottleneck when services are geographically distributed or have poor network connectivity. While resource constraints can exacerbate the issue, the initial symptom – increased delay between emission and consumption – strongly points to network issues rather than immediate service overload.

The key advantage of event-driven architecture is loose coupling. Publishing 'CustomerProfileUpdated' events allows services to react to changes independently and asynchronously. This decoupling prevents cascading updates and ensures that modifications don't inadvertently affect other systems – a direct update would create tight dependencies.

Event replay is a critical feature for robust event-driven systems. Retention policies allow consumers to recover from transient issues (like temporary service outages) or reprocess events if they've been corrupted. This capability dramatically improves system resilience and reliability – simply reducing storage costs isn't the primary goal here.

Eventual consistency is a fundamental trade-off in event-driven architectures. Because events are processed asynchronously, there's a delay between when an update occurs and when all consumers have seen it. Managing this inconsistency requires careful design and monitoring to ensure data integrity – the other options represent different concerns within a broader system.

The core concept here is understanding that event-driven architectures rely on asynchronous communication. Increased latency doesn't automatically mean a problem; it's often due to processing time within the consuming service. Option A correctly identifies the root cause - routing issues can introduce delays. Options B and D are misleading – latency isn't inherently bad in an EDA, and successful authentication shouldn't have any performance impact.