# Design Container Assignment with Incompatible Goods Design a service that assigns goods in a shipment to ocean containers while respecting capacity and incompatibility rules. The detailed product rules below are practice assumptions added to make the abbreviated source prompt actionable. ### Constraints & Assumptions - Each item has weight, volume, quantity, handling attributes, and a shipment ID. - Each container type has weight and volume limits. - Some item pairs or hazard classes cannot share a container. - Plans can be drafted, recomputed, approved, and later adjusted before loading. - The optimization goal prioritizes feasibility, then container cost, then unused capacity. ### Clarifying Questions to Ask - Are items divisible across containers? - Are incompatibilities pairwise, class-based, directional, or route-specific? - Must weight distribution or physical geometry be modeled? - Is an exact optimum required, and how much planning latency is available? - Can multiple planners edit the same shipment? ### Part 1: API and Data Model Define goods, compatibility rules, container types, plans, assignments, plan versions, and validation results. Cover create, solve, inspect, approve, and modify operations. #### Hints - Preserve the rules and inputs used to produce an approved plan. #### What This Part Should Cover - Versioned domain model - Auditable validation - Concurrent-edit semantics ### Part 2: Planning Engine Describe feasibility checks, a practical assignment algorithm, exact-solver boundaries, deterministic output, and behavior when no plan is feasible. #### Hints - Separate a fast construction step from improvement. - Treat incompatibility and capacity as different constraints. #### What This Part Should Cover - Correct constraint representation - Scalable optimization approach - Explainable infeasibility ### Part 3: Reliability and Operations Explain asynchronous execution, retries, cancellation, approval races, rule changes, monitoring, and manual override. #### Hints - A solver result can become stale before it is approved. #### What This Part Should Cover - Idempotent jobs and state transitions - Safe publication - Operational and quality signals ### What a Strong Answer Covers - A precise, versioned planning contract - A feasible algorithm with honest optimality trade-offs - Deterministic, auditable plans and useful infeasibility reports - Concurrency control, stale-input protection, and production observability ### Follow-up Questions - How would you add multi-port unloading order constraints? - When would you use integer programming rather than a heuristic? - How would you replan after one container becomes unavailable? - How do you test that rule changes never permit a forbidden pairing?