Message queues & event-driven architecture

Queue = one producer, one consumer (or one message to one consumer). Example: "Process this order." One worker takes it, does the job, and the message is gone.

Pub/sub = one producer, many subscribers. Example: "Order placed." Inventory, email, and analytics all get the same event. Each subscriber gets a copy.

Both decouple producers from consumers. Producer does not wait for the consumer to finish. If the consumer is slow or down, messages wait in the queue or stay in the topic until someone reads them.

Use a queue when each piece of work should be done once (e.g. process payment, send one email). Competing consumers take messages; only one gets each message.

Use pub/sub when one event should trigger many actions (e.g. "user signed up" → send welcome email, update CRM, add to analytics). Each subscriber gets the event; you can add new subscribers without changing the producer.

Cloud: SQS (queue), SNS (pub/sub), EventBridge (events/routing). Same ideas everywhere.

Event-driven = services react to events (order placed, file uploaded) instead of calling each other directly. Loose coupling: the order service does not need to know who cares about "order placed."

Benefits: scale consumers independently, add new features by adding subscribers, and tolerate slow or failing consumers because the message/event is stored until processed.