Notification on state change in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Observer Pattern for State Change Notification

Which design pattern is best suited to notify multiple components when an object's state changes?

A Observer pattern

B Singleton pattern

C Factory pattern

D Decorator pattern

💡 Hint

Think about a pattern where one object informs many others about changes.

The Observer pattern allows an object (subject) to notify multiple observers automatically when its state changes.

❓ Architecture

intermediate

Choosing Components for State Change Notification System

In a system where multiple services need to be notified of a state change in a central component, which architecture component is best to decouple the sender and receivers?

A Direct synchronous API calls

B Message broker (e.g., Kafka, RabbitMQ)

C Shared database polling

D Monolithic service with internal callbacks

💡 Hint

Look for a component that enables asynchronous communication and loose coupling.

A message broker allows asynchronous, decoupled communication between components, improving scalability and reliability.

❓ scaling

advanced

Scaling Notification Delivery for High Volume State Changes

Your system must notify thousands of clients instantly when a state changes. Which approach best ensures scalability and low latency?

A Store notifications in a database and let clients query on demand

B Use a polling mechanism where clients frequently check the state

C Use a push-based pub/sub system with partitioned topics and consumer groups

D Send individual HTTP requests to each client synchronously

💡 Hint

Consider how to handle many clients efficiently without overloading the server.

Push-based pub/sub with partitioning allows distributing load and delivering messages efficiently to many clients.

❓ tradeoff

advanced

Tradeoffs Between Synchronous and Asynchronous Notifications

What is a key tradeoff when choosing synchronous notifications over asynchronous notifications for state changes?

A Synchronous notifications provide immediate feedback but reduce system availability under load

B Asynchronous notifications guarantee delivery order but increase coupling

C Synchronous notifications improve scalability but increase message delay

D Asynchronous notifications require clients to block until notification arrives

💡 Hint

Think about system responsiveness and reliability under heavy load.

Synchronous notifications block the sender until receivers respond, which can reduce availability if receivers are slow or down.

❓ component

expert

Designing a Reliable Notification System with Exactly-Once Delivery

Which component or technique is essential to ensure exactly-once delivery of notifications on state change in a distributed system?

A Relying on client-side retries without server tracking

B Simple fire-and-forget message sending without acknowledgments

C Using UDP protocol for faster message delivery

D Idempotent message processing combined with unique message IDs and persistent storage

💡 Hint

Consider how to avoid duplicate processing despite retries or failures.

Exactly-once delivery requires idempotent processing and tracking unique message IDs to avoid duplicates, often with persistent storage.