Localz — SLOs, Saga, and Bulkhead Patterns (Incremental)
The previous incremental pass mapped secrets management onto Localz's stated problems. Four new Architecture/Fundamentals/ notes landed since then (bulkhead-pattern, saga-pattern, slo-sli-error-budgets, zero-trust-architecture) and haven't been checked against Projects/Localz yet. Three are a strong, direct match; one is a partial fit worth flagging rather than forcing.
SLIs/SLOs/Error Budgets — closes a gap the synthesis itself already flagged
Projects/Localz.md §4 explicitly calls out its own Non-Functional Requirements as "qualitative, not quantified (no explicit SLOs/SLAs, latency targets, or uptime percentages appear in this file)" — a named specification gap, not an oversight this note is inventing. SLIs, SLOs, and Error Budgets is a ready-made framework to close it: pick the critical user journeys directly named in §4 ("quick search, booking, and chat responses," "high uptime to support real-time bookings") and define one SLI per journey — e.g., "% of booking-confirmation requests completing without error within Xms," measured over a rolling 30-day window — rather than leaving "performance" and "availability" as unmeasured adjectives. Given the booking flow already has a stated idempotency-key requirement (per the prior incremental note), an SLO on booking-confirmation success rate is the natural next artifact once that endpoint exists.
Saga Pattern — relevant the moment the modular monolith splits, and worth deciding the shape now
Projects/Localz.md §5 names the "9 domains to separate early" (Identity & Access, Catalog, Orders & Checkout, Payments, Fulfillment, Messaging & Notifications, Media, Search & Discovery, Analytics/Audit) even while starting as one modular monolith with one Postgres database. A confirmed booking today is a single local transaction across Orders/Payments tables — but the moment Payments or Fulfillment splits into its own service (the stated eventual path), "booking confirmed + charge succeeded + provider notified" stops being one ACID transaction and becomes exactly the cross-service consistency problem Saga Pattern describes. Worth deciding now, while still a monolith, which compensating action covers each step ("release the held slot," "refund the charge," "notify provider of cancellation") — designing the compensation logic is far cheaper before the database boundary actually splits than after. The note's own guidance on choreography vs. orchestration also gives a concrete framing for the "message-bus boundaries early" instruction already in Tech-Stack.md: a small number of participants (booking → payment → fulfillment) fits choreography's simpler event-chain model better than a dedicated orchestrator, at least at Localz's current scale.
Bulkhead Pattern — the concrete answer to Redis being a shared, mandatory dependency
Redis is already committed as mandatory at MVP (§5) for caching, sessions, OTP throttles, rate limiting, and Pub/Sub fanout — a single shared pool serving every consumer and provider on the platform. Bulkhead Pattern names the exact risk this creates: one provider's traffic spike (a popular listing going viral, a scraping bot, a retry storm from a buggy client) exhausting the shared Redis connection pool would degrade OTP throttling and rate limiting for every other user simultaneously — the opposite of what those features exist to protect against. Worth deciding, before launch, whether per-tenant/per-endpoint connection or rate-limit partitioning (the note's platform-quota mechanism, not a hand-rolled thread pool) is needed on Redis specifically, since it's the one dependency named as sitting in the request path for nearly every feature (search, chat fanout, sessions, throttling) at once.
Zero Trust Architecture — partial match, noted for completeness rather than forced
Zero Trust Architecture is written for distributed/hybrid enterprise workforces and multi-cloud environments — a shape Localz doesn't have yet as a pre-launch, single-repo startup with no internal workforce-perimeter problem to solve. The one piece that does transfer: the note's warning against "SSO/MFA at the login screen while internal service-to-service traffic still trusts anything on the same network" is worth keeping in view for whenever the modular monolith splits into services (same trigger as the Saga Pattern match above) — at that point, service-to-service calls between Payments, Fulfillment, and Messaging would otherwise inherit implicit trust from being on the same VPC, which is precisely the anti-pattern the note calls out. Not actionable pre-launch; worth revisiting alongside the saga-pattern decision once services actually split.
Suggested next step
The SLO gap is the most immediately actionable item — it requires no new infrastructure, just picking numbers for journeys Localz has already named qualitatively in its own NFRs. The saga/bulkhead items are pre-launch design decisions worth making explicit now (compensation logic, Redis partitioning) even though their infrastructure trigger (service split, real traffic volume) hasn't happened yet — cheaper to decide the shape before the monolith splits than to retrofit it after.