Events & Messaging
Event-driven architecture, queues, Kafka-style logs, and the sync-vs-async decision — with duplicates, ordering and replay taken seriously.
A producer records that something happened and stops caring who listens; consumers subscribe and react on their own clock — which buys decoupling and fan-out at the price of eventual consistency, duplicate delivery, ordering you must design for, and a "who owns the truth" question you must answer explicitly.
A queue turns "call Service B now" into "hand Service B a message it will process when it can" — buying failure isolation and a buffer for bursts, at the price of ack/retry/visibility-timeout semantics, dead-letter handling and a backlog you must watch.
A topic is a set of append-only partition logs; a consumer group splits the partitions and remembers an offset per partition — which gives per-partition ordering, replay from any offset and many independent readers, and makes the partition key and consumer lag the two decisions that determine whether the system behaves.
Call synchronously when the caller needs the answer now, the chain is short and consistency must be immediate; go asynchronous when the work can happen later, fan out, or arrive in bursts — and use the hybrid, a synchronous command with asynchronous consequences, for most real user-facing writes.