Composable Event Recommendation Campaign Engine (Flexible Filters + Ranking + Fallback)

Design a flexible event recommendation framework that powers various marketing campaigns through the composition of reusable components. Avoid hardcoding individual campaigns with scattered conditional logic. Instead, build extensible abstractions such as filters, rankers, scorers, and a pipeline or strategy that orchestrates them.

Provided Models & Services

• Event {id, name, city, date}
• Customer {id, name, city}
• Inventory {eventId, price, quantity}
• EventsService.getEvents() — fetches all candidate events
• InventoryService.getInventory() — fetches inventory and pricing data
• UsersService.getCustomer() — fetches the target user
• LocationService.getLocationCoordsByCity(city) — returns geographic coordinates for a city
• LocationService.calculateDistanceInMiles(coord1, coord2) — computes the distance between two coordinate pairs

Composable Campaign Behaviors

The system must support pluggable capabilities that can be mixed and matched:

1. Proximity Filtering — Include only events whose venue is within a specified mileage radius of the user (e.g., 100 miles), or that share the user’s city.
2. This Weekend — Include only events occurring during the upcoming weekend (Saturday and Sunday).
3. Next 30 Days — Include only events whose date falls within the next 30 days, starting from the current moment.
4. Budget-Friendly — Include only events whose Inventory.price is below a given threshold (e.g., $50).
5. Fallback — Guarantee that the user receives at least a minimum number of recommendations (e.g., at least 1 or N) even when the matched result set is too small, by progressively relaxing constraints or pulling from a broader candidate pool.

Your Task

Implement an entry point method such as:

List<Event> recommend(Customer user, Campaign campaign, int limit)

A Campaign definition should be built via composition and include:

• One or more filter predicates combined with AND / OR logic
• A ranking or scoring strategy (e.g., by distance, by price, or a weighted combination)
• A fallback policy that specifies how to relax constraints step by step or fill gaps from a wider pool

Constraints & Edge Cases

• Never write campaign‑specific branches inside the core logic; rely on reusable abstractions.
• Join Event and Inventory on eventId where necessary.
• Define clear behavior when all applied filters produce an empty set.
• Assume location coordinates are always available; if they could be missing, describe your mitigation approach.
• The returned list must contain at most limit events, ordered by the campaign’s ranking strategy.

Scale Assumptions

• Up to 100,000 events
• Up to 100,000 inventory records
• limit up to 100

Campaign Scenarios

1. Campaign A — Filters: within 100 miles OR price < $50. Rank using a combined score of proximity and price. Return the top 5.
2. Campaign B — Filters: this weekend AND price < $50. If the result set is empty, fallback to within the next 30 days. Return the top 5.
3. Campaign C — Filters: within the next 30 days. Rank by nearest upcoming date. Return the top 5.

The design goal: adding a novel filter or ranker should primarily mean introducing a new component, not rewriting existing orchestration logic.

Example

• Input: Campaign A, limit = 5, user city = San Francisco (use sample Events/Inventory provided in your environment)
• Output: Print the 5 recommended events ordered by the campaign’s ranking rule. The exact ordering depends on your combined scoring definition. Ensure the returned list is non‑empty.