Design Composable Event Recommendations

Build a flexible event recommendation engine for a ticket marketplace. You are given these domain objects and services: - `Event(id, name, city, date)` - `Customer(id, name, city)` - `Inventory(eventId, price, quantity)` - `Coordinates(x, y)` - `EventsService.getEvents()` returns events. - `InventoryService.getInventory()` returns inventory records. - `UsersService.getCustomer()` returns the current customer. - `LocationService.getLocationCoordsByCity(city)` returns city coordinates. - `LocationService.calculateDistanceInMiles(x1, y1, x2, y2)` returns distance between two coordinate points. Sample data includes events in cities such as San Francisco, Los Angeles, New York, Chicago, Austin, and Boston; inventory prices ranging from about $25 to $95; and a sample customer named Alice in San Francisco. Product insights: - Users are more likely to engage with events within 100 miles of their home city. - Events with inventory priced under $50 convert at a higher rate. - Events happening this weekend or within the next 30 days drive stronger engagement. - Users in metro areas may purchase tickets in adjacent cities. - Campaigns that return some relevant events perform better than campaigns that return no events. - Future signals may include artist hometown affinity, seasonal or weather effects, and handling repeated event names across multiple cities. Implement a recommendation engine that supports different marketing campaigns without hard-coding each campaign's logic. Requirements: 1. Join events with inventory and only recommend events that have available quantity. 2. Support reusable recommendation rules, such as: - events in the user's city, - events within 100 miles of the user's city, - events priced below $50, - events happening this weekend, - events happening within the next 30 days. 3. Allow campaign rules to be composed with logical operations such as AND and OR. 4. Support configurable ranking, such as nearest distance, lowest price, soonest date, or a weighted score. 5. Support fallback behavior so a campaign can return broader recommendations if the primary rule produces no results. 6. Avoid duplicate events in the final result. 7. Handle edge cases such as missing coordinates, missing inventory, unknown city, zero inventory, and ties in ranking. 8. Demonstrate the design with at least one campaign, for example: recommend events that are either within 100 miles of the user or priced under $50, then rank them by distance and price. Use Java or clear pseudocode. The main evaluation criterion is whether the design is extensible and composable rather than a set of one-off hard-coded filters.