Localz — Zone-Resilience and Fleet Self-Healing (Incremental)
The previous incremental pass mapped SLOs, the saga pattern, and the bulkhead pattern onto Localz's stated problems. Two new Architecture/CaseStudies/ notes landed after that pass and haven't been checked against Projects/Localz yet.
Uber: Zone-Failure-Resilient OpenSearch — directly names a technology Localz's own stack docs are still deciding on
Projects/Localz.md §5 lists OpenSearch (Serverless) as one of two named alternatives for search/discovery (the other being Typesense/Meilisearch), and §4 names "Availability — high uptime to support real-time bookings" as a stated (if unquantified) NFR. Uber: Zone-Failure-Resilient OpenSearch is a close match on the specific technology, not just the general availability goal: its core lesson — that OpenSearch's shard allocation awareness alone assumes node-to-zone placement stays stable, which a container orchestrator doesn't guarantee without an extra placement layer — is exactly the kind of detail that would otherwise surface for the first time during an actual zone outage. This isn't actionable today (Localz's own Strategy Note, per the prior incremental pass's context, defers adding a dedicated search engine at all until query volume justifies it), but it's a concrete decision-input worth attaching now: if/when OpenSearch is picked over Typesense/Meilisearch, this case study is the first thing to read, since it changes how the search-availability NFR would actually be sized (shard-copy count, cluster-manager count, isolation-group-equivalent on whatever orchestrator Localz ends up using).
Stripe: Graph Search and State Machines to Auto-Remediate a Global Database Fleet — real pattern match, wrong scale for now
Stripe: Graph Search and State Machines to Auto-Remediate a Global Database Fleet targets MongoDB specifically — a store already committed in Projects/Localz.md §5 for provider profiles, service catalogs, and chat threads. The underlying idea (model failure/repair as a graph instead of hand-writing runbooks) is a genuinely good long-term answer to "how does Localz recover degraded Mongo state without an engineer paged every time," but Stripe's case study is solving this at 2,000+ shards — several orders of magnitude past a pre-launch, single-region MVP with one Mongo Atlas cluster. Forcing this match now would be over-engineering; flagging it here so it isn't rediscovered from scratch once Mongo operational toil becomes a real cost (a trigger comparable to the ones already named in Projects/Localz.md's Observability Stack section — e.g., "APM when latency debugging hurts").
Suggested next step
Neither item is actionable pre-launch. The OpenSearch case study is the more concrete of the two — worth a one-line pointer added to Tech-Stack.md's search-engine section (or Projects/Localz.md §5's OpenSearch row) so the zone-resilience caveat isn't lost by the time the search-engine decision actually gets made. The Stripe case study is filed as forward context only; no action until Mongo fleet size or operational toil makes it relevant.