Pub-sub

# Overview A communication approach where a single service is responsible for collecting updates from a source and broadcasting them to all interested clients. # Key Considerations # Pros of Pub-Sub #flashcard - Managing load on endpoint servers is easy, we can use a simple load balancer with "least connections" strategy - We can broadcast updates to a large number of clients efficiently - We minimize the proliferation of state through our system.  # Cons of Pub-sub #flashcard - We don't know whether subscribers are connected to the endpoint server, or when they disconnect - The Pub/Sub service becomes a single point of failure and bottleneck - We introduce an additional layer of indirection which can add to latency - There exist many-to-many connections between Pub/Sub service hosts and the endpoint servers DELETE  # Use Cases # Related Topics - [[Kafka]] - [[Redis]] --- Things to discuss when using Pub-Sub in a system design interview... #flashcard - Talk about the single point of failure and bottleneck of the pub/sub service. Redis cluster is a popular way to scale pub/sub service which involves sharding the subscriptions by their key across multiple hosts. This scales up the number of subscriptions you can support and the throughput. - You'll manage the many-to-many connections between the pub/sub service and the endpoint servers (each endpoint server will be connected to all hosts in the cluster). In some cases this can be managed by carefully choosing topics to partition the service, but in many cases the number of nodes in the cluster is small. - For inbound connections to the endpoint servers, you'll probably want to use a load balancer with a "least connections" strategy. This will help ensure that you're distributing the load across the servers in the cluster. Since the connection itself (and the messages sent across it) are effectively the only resource being consumed, load balancing based on connections is a great way to manage the load.  ---