Worth reserving? II

Building a profitable GPU capacity broker in Python

This is a medium-difficulty systems design problem that tests your ability to implement an event-driven state machine under real-world constraints. Rather than a single correct answer, the challenge is to write clean, maintainable Python code that balances competing objectives: profitability, latency, and correctness under market uncertainty.

The core problem is resource-matching under asymmetric information. You see jobs and capacity blocks arrive asynchronously, must decide whether to reserve (and pay for) blocks without knowing what jobs will arrive later, and must schedule claimed jobs onto reserved blocks before their windows open. The profit constraint—blocks must be at least 80% full to break even—forces you to be selective about reservations. The constraint that you're penalized for claiming jobs you don't schedule forces you to claim only when you have a concrete placement ready.

Strong solutions separate concerns: track available blocks and jobs in a way that makes it fast to query "which jobs fit this block," implement a reservation policy that respects the 80%-fill threshold and the 6-hour lookahead window, and structure the on_timer dispatch so that matching logic runs deterministically each tick. You'll also need to handle graceful failure—when a reservation or claim fails, the code should recover and retry rather than drop state.

• Event-driven architecture and state management
• Greedy matching and bin-packing heuristics
• Handling non-deterministic network calls (reserve and claim can fail)
• Time-window filtering and constraint satisfaction