Messaging

Messaging

Kafka, event-driven architecture, outbox and CQRS, WebSockets, MQTT, and queues you can defend in interviews.

• Event-Driven Architecture

  6 studies
  1. 1.Event-Driven Architecture — Sync vs Events, Patterns & TradeoffsEvent-driven architecture publishes facts that already happened. This hub maps sync versus events, notification versus carried state versus sourcing, and where CQRS, the outbox, ordering, and failure modes sit.
  2. 2.Event Types — Notification, Event-Carried State Transfer & Event SourcingNotification, event-carried state transfer, and event sourcing are different contracts. Payload richness decides coupling, races, and whether the log is the source of truth.
  3. 3.CQRS — Commands, Queries, Projections & ConsistencyCQRS splits commands that change state from queries shaped for screens. In an event-driven system the read side is usually a projection, and lag is an SLO rather than a stuck write.
  4. 4.Transactional Outbox, Inbox & Consumer IdempotencyA dual-write commits the database and publishes as two steps, so one can succeed alone. The outbox makes the intent to publish part of the local commit. The inbox makes at-least-once delivery safe.
  5. 5.Ordering, Partitions, Poison Messages & Retry/DLQ StrategyMost event-driven flows need order per entity, not global order. Partitions buy parallelism. Bounded retries and a dead-letter path keep one poison message from stalling that entity.
  6. 6.EDA Failure Modes — Dual Writes, Schema Drift & Fan-out Blast RadiusEvent-driven systems fail in known ways: dual-write loss or ghosts, schema changes that break a fleet, and one poison event amplified across every consumer. Containment is outbox, compatible rollout, and per-consumer isolation.

• Kafka messaging

  5 studies
  1. 1.Apache Kafka — Topics, Partitions, Brokers & Consumer GroupsAppend-only partitioned logs; consumer group assigns each partition to at most one member; durability=ISR; scale=partitions; order=within partition.
  2. 2.Partition Keys — Ordering Guarantees vs Parallel Throughputhash(key)%N sticky order; null keys sticky/RR; repartition breaks affinity; hot keys/sticky partitioner.
  3. 3.Delivery Semantics — At-Least-Once, At-Most-Once & Exactly-OnceAMO vs ALO vs EOS (idempotent producer+transactions); external side effects still need idempotency keys.
  4. 4.Consumer Rebalancing, Lag & BackpressureCooperative sticky vs eager; lag as offset gap; pause/resume; scale consumers vs partitions.
  5. 5.Schema Evolution, Compatibility & Dead Letter QueuesAvro/Protobuf/JSON Schema; FORWARD/BACKWARD/FULL; poison→DLQ/retry; never block forever on bad payload.

• WebSockets & MQTT

  6 studies
  1. 1.WebSockets & MQTT — Real-Time Protocols for Senior InterviewsInterviewers ask how you push live updates without burning sockets, batteries, or ops. WebSockets give full-duplex browser streams; MQTT gives topic-based pub/sub for devices. SSE, long-polling, and Kafka-style logs fill different niches — this hub maps the cluster.
  2. 2.WebSocket Protocol — Handshake, Frames, Ping/Pong & Close CodesRFC 6455 upgrade is HTTP 101 plus Accept = base64(SHA1(key + GUID)). Frames carry opcodes and masking; ping/pong is the application keepalive. Close 1001 drains deploys; 1006 is an abnormal drop with no close frame.
  3. 3.MQTT Essentials — Topics, QoS 0/1/2, Retained Messages & SessionsMQTT is broker-centric pub/sub: hierarchical topics, hop-scoped QoS 0/1/2, retained last-value, and clean vs persistent sessions. Effective QoS is the min of publish and subscribe. QoS 2 is not Kafka exactly-once.
  4. 4.WebSocket vs SSE vs Long-Polling vs MQTT — When to Choose WhatChoose a realtime channel from directionality, client environment, proxies, battery, topic routing, and durability. Pick the simplest protocol that fits; bridge to Kafka only when replay is a product requirement.
  5. 5.Scaling WebSockets — Sticky Sessions, Fan-out & BackpressureA WebSocket is pinned to the process that accepted the TCP connection. Sticky affinity reduces reconnect churn, but multi-node rooms need a fan-out bus. Bounded queues, coalesce, and disconnect-slow-clients keep one laggy socket from OOM-ing the node.
  6. 6.MQTT Brokers, Auth & Bridging — ACL, Wildcards, Last Will & Bridge PatternsThe broker authenticates, ACLs by topic, stores retained and sessions, and publishes Last Will on unclean disconnect. Namespace tenants; never grant # to untrusted clients. Bridge with prefix rewrite so topics cannot loop. MQTT QoS 2 is still not Kafka exactly-once.