Exercise 2: The Sort's Purpose and Its Convergence Across All Four Courses — Possible Solution
====================================================================

HOW THE SORT SERVES CHAPTER 1'S ORIGINAL INTENT
------------------------------
Chapter 1 described the recipe-lookup feature as helping suggest recipes for ingredients close to expiring - with the underlying goal being to actually use up as much soon-to-expire food as possible, not just find any recipe containing one matching ingredient somewhere on a long list. Sorting the merged results by len(matched_ingredients) in descending order places recipes using the greatest number of the user's own expiring ingredients at the top, directly surfacing the suggestions that would help use up the most expiring food in a single meal.

WHY THIS LOGIC IS ESSENTIALLY IDENTICAL ACROSS ALL FOUR COURSES
------------------------------
Every course in the quartet has to solve the exact same underlying problem after fanning out its own ingredient requests: given a set of recipes, each tagged with which of the user's expiring ingredients it uses, rank them by how many of those ingredients each one covers. That ranking logic - count the matches, sort descending - doesn't depend on Firestore, Django's ORM, or FastAPI's own request handling at all; it's pure post-processing of already-fetched data, so each course implements the identical idea in its own language's own idioms, arriving at functionally the same behavior.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that the sort directly serves the goal of using up the most expiring ingredients at once, and correctly identifies that this specific piece of logic is independent of any course's own backend/database architecture, which is exactly why all four courses converge on the same approach here despite diverging everywhere else.