Design Patterns interview question · Most asked
Scenario: when an order is placed, several systems (email, inventory, analytics, loyalty) must react, and more will be added. How do you design it?
Summary
Publish an OrderPlaced event and let each system subscribe: Observer in-process, or Pub/Sub through a broker if the reactions are slow, unreliable or in other services. Order placement no longer knows its consumers.
Longer Answer
With a broker (SQS/SNS, Kafka, RabbitMQ), use the transactional outbox pattern so the event is published only if the order is committed, make subscribers idempotent (at-least-once delivery), and add dead-letter queues. In-process observers are fine for fast, reliable reactions in a monolith.
Key Points
- Event + subscribers.
- Observer in-process, Pub/Sub across services.
- Outbox for reliable publishing.
- Idempotent subscribers and DLQs.
Deep dive: Design Patterns, Explained Simply: Pub/Sub and the Event Bus
Explanation
What interviewers look for
Decoupling plus reliability concerns (outbox, idempotency).
More most-asked Design Patterns questions
- What problem does the Builder pattern solve? Show an example.
- Explain the SOLID principles.
- What is a design pattern, and why are they useful?
- What is the difference between dependency inversion, dependency injection and inversion of control?
- Why is composition often preferred over inheritance?
- What is dependency injection, and what forms does it take?
- Explain the Factory Method pattern and how it differs from a simple factory.
- How do you implement a Singleton, and why is it often considered an anti-pattern?