Exercise 1: Evaluating an Internal Wiki Against the Decision Framework — Possible Solution ==================================================================== THE SCENARIO ------------------------------ An internal company wiki has a basic search box used occasionally by 50 employees. QUESTION 1: IS SEARCH A PRIMARY PRODUCT FEATURE, OR A SECONDARY CONVENIENCE? ------------------------------ Secondary. The wiki's own primary purpose is storing and presenting internal documentation — search is a convenience feature helping employees find existing content, not the product itself. Per this chapter's own framework, "secondary → postgres1-6 is probably enough." QUESTION 2: DOES THE DATASET/QUERY VOLUME GENUINELY REQUIRE HORIZONTAL DISTRIBUTION? ------------------------------ No. "Occasionally by 50 employees" describes genuinely low, modest query volume, and an internal company wiki's own document count is very unlikely to approach anything close to the scale that would challenge a single well-resourced Postgres server. QUESTION 3: IS FACETED SEARCH/REAL-TIME AGGREGATION A GENUINE, HEAVILY-USED PRODUCT REQUIREMENT? ------------------------------ Nothing in the scenario suggests this at all — a "basic search box" implies simple text search, not a faceted filtering interface with category/price-style breakdowns the way search1-7's own e-commerce example described. QUESTION 4: DOES RELEVANCE QUALITY ITSELF MATERIALLY AFFECT THE PRODUCT'S OWN SUCCESS? ------------------------------ Unlikely. For an occasionally-used internal tool with 50 employees, "the search works and finds roughly the right documents" is very likely sufficient — there's no indication that sophisticated BM25- style relevance tuning (search1-6) is what determines whether this internal wiki succeeds or fails as a product, the way it might for a genuine, revenue-driving e-commerce search experience. QUESTION 5: IS THE TEAM PREPARED TO OPERATE AND MAINTAIN AN ENTIRELY SEPARATE DISTRIBUTED SYSTEM? ------------------------------ Even if the team were technically capable, per this chapter's own "Real Operational Cost" section, doing so here would mean taking on "real infrastructure, real operational expertise, and real ongoing complexity keeping two systems in sync" purely to serve an occasionally-used internal tool for 50 people — a real, ongoing cost with no corresponding real benefit given the answers to questions 1-4. CONCLUSION ------------------------------ postgres1-6's own built-in full-text search is clearly the better fit here. All five framework questions point away from a dedicated search engine: search is secondary, scale is modest, faceting isn't needed, relevance sophistication isn't a real success driver, and the real operational cost of a separate distributed system has no corresponding benefit for this specific use case. WHY THIS WORKS AS AN ANSWER ------------------------------ It applies each of the chapter's own five framework questions individually to the specific scenario, reasoning from the details actually given, and reaches a conclusion that follows consistently from all five answers together.