HTML MASTER CLASS /// LEARN TAGS /// BUILD STRUCTURE /// SEMANTIC WEB /// HTML MASTER CLASS /// LEARN TAGS ///

Untitled Lesson

⚡ Total XP: 0|💻 backend XP: 0

Skill Matrix

UNLOCK NODES BY LEARNING NEW TAGS.

Select an unlocked node to view details root

Pascual Vila

Frontend Instructor // Code Syllabus

Common Pitfalls & Errors

The Error //

Using plain Redis Pub/Sub for a message that must never be lost, such as a payment confirmation

// Wrong: a payment confirmation that could be silently lost forever
await redisPublisher.publish("payment-confirmed", data);

// Correct: persisted, replayable even if a consumer was briefly offline
await redis.xadd("payment-events", "*", "type", "PaymentConfirmed", "data", JSON.stringify(data));

The Solution //

Plain Redis Pub/Sub is fire-and-forget with no persistence — if the intended subscriber isn't actively connected at the exact moment of publishing, that message is gone permanently, with no way to recover or replay it. Use a durable option (Redis Streams, RabbitMQ, or Kafka) for any message where loss is genuinely unacceptable.

The Error //

Assuming a subscriber that reconnects after being briefly offline will automatically receive messages it missed while disconnected

// Wrong assumption: reconnecting subscriber does NOT catch up automatically
redisSubscriber.subscribe("order-events"); // starts fresh, missed messages are gone

// Correct: a durable stream a consumer can read from where it left off
await redis.xread("BLOCK", 0, "STREAMS", "order-events", lastProcessedId);

The Solution //

Plain Redis Pub/Sub delivers a message only to subscribers actively connected at the exact instant it's published — there is no buffering or replay mechanism for a subscriber that reconnects later. If catching up on missed messages matters, a durable queue with persistence and consumer acknowledgment is required instead.