<Mr. Dev/>
All notes

02 # EXPLORING

Kafka vs RabbitMQ · REST vs gRPC · Event-driven architecture

TECHNICAL NOTE

Match the communication model to the failure model.

Commands and facts have different needs. Synchronous calls help when a user needs an immediate answer. Durable events help independent systems react without becoming tightly coupled.

COMMON USES

Domain events

Kafka when several consumers need an ordered, replayable history of facts such as a created order or updated record.

Background work

RabbitMQ for focused task dispatch, routing, acknowledgements, and worker-level retries.

Product APIs

REST at external boundaries; gRPC between owned services where typed contracts and streaming earn their operational cost.

QUESTIONS

Choices depend on context

01 # Event transport

Kafka or RabbitMQ?

Kafka

A durable, partitioned log that consumers can replay.

  • Strong fit for event streams and analytics.
  • Consumers control their reading position.
  • Requires partition and retention design.

RabbitMQ

A broker optimized for routing messages to workers.

  • Direct task queues and flexible routing.
  • Acknowledgement and retry workflows are straightforward.
  • Not a long-lived event history.

ConclusionKafka fits a product fact with multiple consumers. RabbitMQ fits a unit of work that one worker needs to own and finish.

02 # Request APIs

REST or gRPC?

REST

Resource-oriented HTTP interfaces with broad ecosystem support.

  • Easy to inspect, cache, and integrate.
  • Natural fit for browsers and third parties.
  • Schemas need disciplined versioning.

gRPC

Contract-first RPC over HTTP/2 with generated clients.

  • Efficient internal calls and streaming.
  • Compile-time contract feedback.
  • Browser and debugging workflows need extra tooling.

ConclusionREST works well for public and browser-facing APIs. Use gRPC on high-volume internal paths when its contracts or streaming solve a measured problem.

TAKEAWAY

Event-driven architecture removes temporal coupling, not responsibility. The work moves into contracts, retries, ordering, and observability.

POINTS TO KEEP IN MIND

  • Make consumers idempotent; delivery is usually at-least-once in practice.
  • Version event contracts and keep schemas compatible.
  • Use an outbox or equivalent handoff so database writes and published events cannot silently diverge.
  • Plan retry limits, dead-letter handling, and observability before the first consumer ships.