Building an event-driven order router with the Observer pattern
This is a medium-difficulty Python design-patterns problem that tests whether you can implement the Observer pattern to decouple routing logic from venue-specific handling. It's the kind of architectural question quant trading firms like DE Shaw ask to see if you can write extensible, maintainable code under interview conditions.
The core challenge is to set up a publish–subscribe mechanism where a central router broadcasts order events to multiple handlers, each of which independently decides whether to process the order. Handlers should be loosely coupled: adding a new venue should require no changes to the router itself. Strong solutions define a clear base interface, implement filtering logic inside each handler rather than in the router, and cleanly separate registration from event dispatch.
- Inheritance and abstract base classes
- Maintaining and iterating over a handler registry
- Filtering and conditional logic in handler implementations
- Return value aggregation from multiple observers