Getting Ready: Pub-Sub System

Every modern software system that needs to move information between independent components relies on some form of publish-subscribe (pub-sub) messaging. When a user places an order on Amazon, the order service doesn't directly call the inventory service, the payment service, the notification service, and the analytics service one by one. Instead, it publishes an "order placed" event, and every service that cares about that event picks it up independently. This decoupling is what makes systems like Amazon, Uber, Netflix, and Slack possible at scale.

The pub-sub pattern powers some of the most critical infrastructure in the industry. Apache Kafka processes trillions of messages per day at LinkedIn. Google Cloud Pub/Sub routes events across Google's internal services. Redis Pub/Sub provides lightweight real-time messaging for chat applications and live dashboards. RabbitMQ handles millions of messages per second in financial trading systems. AWS SNS fans out notifications to millions of subscribers across email, SMS, and push channels.

Interviewers love this problem because it sits at the intersection of several important design concepts. You need to model the relationship between publishers and subscribers (Observer Pattern), manage topic-based message routing through a central broker (Mediator Pattern), handle subscriber lifecycle management, and think about thread safety when multiple publishers and subscribers operate concurrently. It's a medium-complexity problem that naturally exercises OOP relationships, interface design, and concurrency awareness -- all in a compact, well-scoped system.

By the end of this design problem, you will be able to:

• Apply the Observer Pattern as the core pub-sub mechanism -- topics notify all their subscribers when a new message arrives (Fundamentals S12)
• Apply the Mediator Pattern to route messages through a central broker, decoupling publishers from subscribers entirely (Fundamentals S12)
• Design a clean class hierarchy with interfaces, concrete classes, and well-defined composition and association relationships (Fundamentals S4)
• Model topic-based routing where messages are delivered only to subscribers of the relevant topic
• Build a thread-safe extension that handles concurrent publishers, dynamic subscriber management, and safe message delivery using locks and snapshot iteration
• Create UML class and sequence diagrams that trace directly back to requirements
• Implement the full system in both Python and Java with compilable, runnable code

Before starting this problem, make sure you're comfortable with:

• OOP Relationships -- especially Composition (broker owns topics) and Association (topics reference subscribers) (Fundamentals S4)
• Interfaces and Abstract Classes -- the Subscriber interface is central to the design (Fundamentals S4)
• Observer Pattern -- this entire system is a sophisticated application of Observer. Make sure you understand subjects, observers, and notification mechanics (Fundamentals S12)
• UML Class Diagrams -- how to read and draw class boxes, relationship arrows, and multiplicities (Fundamentals S5)
• Basic Concurrency Concepts -- locks and thread safety will be needed for the extension tutorial (Fundamentals S14)

If you've completed any of the Easy difficulty problems (DP1-DP7), you're well-prepared. This Medium problem builds on those foundations by introducing multiple interacting components and a concurrency extension.

We will design: The core domain logic of a pub-sub messaging system -- the broker that manages topics, the topics that hold subscriber lists, the publishers that create and send messages, and the subscribers that receive them. We will also design thread-safe message delivery for concurrent access.

We will NOT design: Network protocols (TCP/HTTP for message transport), message persistence (disk-based queues like Kafka's commit log), distributed systems concerns (partitioning, replication, consumer groups), serialization formats (Protobuf, Avro), or REST/gRPC APIs. This is a Low Level Design (object-oriented) exercise focused on the in-memory class structure and interactions, not a System Design (infrastructure) problem.

What makes this problem interesting at the OOP level:

• The broker acts as a Mediator -- publishers and subscribers never know about each other directly
• Topics manage their own subscriber sets, which raises questions about ownership semantics (composition vs. aggregation)
• Message delivery must handle dynamic subscribers -- what happens if a subscriber unsubscribes while messages are being delivered?
• The system naturally leads to a thread-safety discussion -- multiple publishers sending to the same topic simultaneously