Part 4 · 1 chapters · ~8 min

Caches and Queues as Standard Equipment

Redis, Memcached, RabbitMQ, SQS, Kafka and NATS: what each is for, what each is paired with, and the signals that tell you it is time to add one.

6

Which one, and when

signaladd
the same expensive read happens thousands of times a minuteRedis or Memcached as a cache
requests do slow work (email, PDF, webhooks) before respondinga job queue: Redis-backed (BullMQ, Sidekiq, Celery) or RabbitMQ / SQS
several services need to react to the same business eventa pub/sub or log: SNS+SQS, Kafka, NATS
you need replay, audit or rebuilding read modelsKafka (retained log)
rate limits, sessions, distributed locksRedis
CACHES AND QUEUES AS STANDARD EQUIPMENT
the shared infrastructure most services lean on
RedisData structures in memory: cache,sessions, rate limits, locks,simple queues, pub/sub, streams.MemcachedSimple multi-threaded key-valuecache. No persistence, no datatypes. Still great for purecaching.RabbitMQMessage broker: exchanges route toqueues, per-message acks, retries,dead letters. Task queues.SQSManaged queue: no servers,at-least-once, visibilitytimeouts, DLQs. FIFO queues forordering.KafkaA partitioned, replicated log.Replayable event streams, highthroughput, consumer groups.NATSLightweight messaging withJetStream persistence. Lowlatency, simple ops, popular withGo.
swipe the figure sideways, or tap expand for full screen
1/6
Redis
Redis is the Swiss army knife: one deployment often serves caching, sessions, rate limiting and job queues (BullMQ, Sidekiq). Split those uses into separate instances as load grows, because eviction policies differ.
cache, sessions, limits, queues in oneseparate instances per use as you grow