Food Delivery Order Matching

Core classes

class Order { Restaurant restaurant; List<OrderLine> lines; Location deliveryLocation; DeliveryPartner assignedPartner; }
class DeliveryPartner { String id; Location currentLocation; boolean available; }
class Restaurant { Location location; }

interface MatchingStrategy {
    Optional<DeliveryPartner> findPartner(Order order, List<DeliveryPartner> availablePartners);
}

Nearest-partner matching as an injectable Strategy

class NearestPartnerStrategy implements MatchingStrategy {
    public Optional<DeliveryPartner> findPartner(Order order, List<DeliveryPartner> availablePartners) {
        return availablePartners.stream()
            .filter(p -> p.available)
            .min(Comparator.comparingDouble(p -> distance(p.currentLocation, order.restaurant.location)));
    }
    private double distance(Location a, Location b) { /* haversine or simple Euclidean for LLD-scope */ return 0.0; }
}

class MatchingEngine {
    private final MatchingStrategy strategy; // swappable — nearest-partner today, utilization-balanced tomorrow

    Optional<DeliveryPartner> match(Order order, List<DeliveryPartner> availablePartners) {
        return strategy.findPartner(order, availablePartners);
    }
}

Same Strategy shape as every matching/allocation problem in this course (Parking Lot's spot allocation, Elevator System's dispatch strategy) — MatchingEngine never hard-codes "nearest wins," it delegates to whichever MatchingStrategy it's configured with.

Plugging into HLD-level geospatial matching

This LLD design's distance() calculation and linear availablePartners scan are appropriately simplified for a class-design exercise — at real scale, finding nearby available partners efficiently is exactly the geospatial indexing problem covered in Design a Ride-Sharing System (Redis GEO/geohash, or a quadtree), not a linear scan over every partner in the system. The connection point is direct: MatchingEngine.match()'s availablePartners parameter, in a real system, would already be a pre-filtered, geospatially-narrowed candidate list (the output of a Redis GEO radius query) rather than the full partner roster — the LLD class design and the HLD geospatial infrastructure compose cleanly, each responsible for a different part of the same problem: HLD narrows "who's nearby," LLD decides "which of the nearby ones actually gets this order."

Follow-up questions this topic invites — and their answers

Q: Why does MatchingEngine take availablePartners as a parameter rather than owning/querying the full partner list itself? A: This keeps MatchingEngine decoupled from wherever partner location data actually lives (an in-memory list here, a Redis GEO index in production) — the caller (which does know how to efficiently fetch nearby available partners) supplies the candidate set, and MatchingEngine's only job is choosing among them, matching the Dependency Inversion principle of depending on what's passed in, not reaching out to a specific data source itself.

Q: How would utilization-balancing (from Design a Ride-Sharing System's matching tradeoffs) be implemented as an alternative MatchingStrategy here? A: A UtilizationBalancedStrategy implementing the same interface, factoring in each candidate partner's recent delivery count or idle time alongside distance — zero changes needed to MatchingEngine or Order, exactly demonstrating the Strategy pattern's swap-without-touching-the-caller benefit in practice, not just in theory.

Q: What happens if the matched partner rejects the delivery offer? A: The matching flow needs a retry loop — similar to Design a Ride-Sharing System's 'offer to nearest, if rejected offer to next' pattern — calling match() again with the rejecting partner excluded from availablePartners, rather than treating a single match() call as guaranteed-final.

Q: Should Restaurant's location factor into partner selection, or should delivery destination matter too? A: A more complete matching strategy would weigh BOTH proximity to the restaurant (for pickup) and the delivery destination (to avoid, e.g., sending a partner already heading the opposite direction) — the simplified NearestPartnerStrategy shown only considers restaurant proximity, which is a reasonable starting scope to state explicitly before optionally extending.