# Filter Open Restaurants Through Existing Domain APIs You are working in an existing codebase with `City` and `Restaurant` abstractions. The provided operations can determine whether a restaurant lies within a requested city's range and whether that restaurant is currently open. Implement the orchestration that returns only restaurants satisfying both conditions. The supplied code is much larger than the required change. Explain which parts of the existing abstractions you need to inspect, how you avoid depending on irrelevant implementation details, and how you would keep the result correct if the provided operations are remote or slow. ### Constraints & Assumptions - Use the range and open-status behavior already provided by the domain abstractions; do not redesign or bypass those contracts. - A restaurant is eligible only when both the city-range check and the open-status check succeed. - The exact API signatures and ordering guarantee are intentionally unspecified. State how your implementation adapts to the contracts found in the supplied code. - Define an explicit policy for duplicate restaurants, empty results, invalid city input, and failed or timed-out checks. ### Clarifying Questions to Ask - Does the city operation return candidate restaurants, test one restaurant, or both? - Is “open” evaluated at the current time, a caller-supplied time, or the restaurant's local time? - Must output preserve source order, use distance order, or provide no ordering guarantee? - Are the supplied operations local calls or network calls, and what rate or concurrency limits do they impose? - Should a failed status check fail the whole request, return a partial result, or mark that restaurant as unknown? ```hint Minimize unnecessary calls Use the cheaper or broader range filter to reduce the set that needs an open-status check when the existing contracts allow it. ``` ```hint Bound concurrency rather than maximizing it If status checks are remote, latency can improve with parallelism, but the implementation still needs timeouts, cancellation, and a limit that protects the dependency. ``` ### What a Strong Answer Covers - Reading just enough of the provided `City` and `Restaurant` interfaces, examples, and tests to identify the supported range and status operations. - A simple correctness path that applies both predicates, handles empty candidates, and avoids returning unknown or failed checks as eligible. - Explicit handling of duplicate IDs, output ordering, null or invalid inputs, time zones, stale status, and dependency failures. - Short-circuiting and candidate reduction before expensive calls, plus bounded concurrency, deadlines, and cancellation when calls are remote. - Cache use only with a freshness policy appropriate to restaurant status, and observability that distinguishes no matches from dependency failure. - Focused tests for boundary distance, opening or closing time, duplicates, partial failures, and deterministic ordering. ### Follow-up Questions 1. How would your implementation change if the open-status call dominates latency? 2. What result should be returned when one restaurant check times out but all others succeed? 3. How would you test a restaurant exactly on the city's range boundary? 4. Which data, if any, is safe to cache, and how would you prevent stale “open” results? 5. How would you cap concurrency when thousands of candidate restaurants are returned?