The use of Server-Sent Events (SSE) for a real-time notification system is quite fitting for the use case described in the article. SSE provides a unidirectional channel from server to client and is ideal when there's no need for client-server communication. It is a more straightforward and lightweight option compared to WebSockets, which provides a bidirectional channel that might be overkill when there's no requirement for client-to-server communication.

The use of Redis Pub/Sub further strengthens the system by enabling the distribution of notifications across multiple pods, ensuring all sellers receive their notifications in a timely manner.

The decision to use SSE over HTTP polling is sound as polling can be resource-intensive and inefficient, especially when many users are subscribed to notifications. Polling involves the client sending requests at an interval, asking the server for new updates. These requests and responses can become numerous and heavy on resources, especially considering the handshake overhead of TCP. In contrast, SSE is lightweight on resources as it involves a single request, with the server sending updates as they occur.

However, it's important to note that although the use of SSE and Redis Pub/Sub is a smart move, the system might face potential scaling challenges as the number of notifications grows. This is because every read API subscribes to all notifications, potentially causing a bottleneck in the system. Filtering notifications based on the client's subscription could become slow and cause delays in sending notifications as the number of notifications increases. Therefore, it's important to plan for potential scalability issues as the system grows and evolves.