Arqly
Sign in
#14Build a pub/sub system (Google Pub/Sub / Redis Pub/Sub style)
stub
One publisher, N subscribers, no shared queue. Build the fanout primitive that powers notifications, cache invalidation, and reactive UIs — with explicit knobs for at-most-once vs at-least-once delivery, durable vs ephemeral subscriptions, and what happens when a slow subscriber stalls the pipe.

Build a pub/sub system (Google Pub/Sub / Redis Pub/Sub style). One publisher, N subscribers, no shared queue. Build the fanout primitive that powers notifications, cache invalidation, and reactive UIs — with explicit knobs for at-most-once vs at-least-once delivery, durable vs ephemeral subscriptions, and what happens when a slow subscriber stalls the pipe.

This problem is a stub. Suggested approaches haven't been authored yet — ask the staff engineer in the right panel for any stage and they'll generate one tuned to your draft.
Reading: Google Cloud Pub/Sub architecture & overview docs · Redis Pub/Sub vs Streams — antirez blog and Redis docs · NATS architecture: subjects, queues, JetStream · AWS SNS — Amazon Builders' Library on fanout · Eugster et al. — The Many Faces of Publish/Subscribe (ACM CSUR 2003) · Confluent — Pub/sub vs queues vs streams (technical comparison)
topic-based fanout (1 publisher → N subscribers)
ephemeral subscriptions (Redis) vs durable subscriptions (Google Pub/Sub)
at-most-once vs at-least-once delivery (no exactly-once at this layer)
subscriber back-pressure: drop, buffer, or block
push delivery (Google Pub/Sub) vs pull delivery (Kafka-style)
filter subscriptions (server-side topic filters)
ordered delivery (per-key) vs unordered fanout
subscription state: cursors, leases, ack windows
fanout amplification: N subscribers × M topics = N·M streams
the slow-subscriber problem and resource isolation
No scenes authored for this problem yet.