Incremental Opportunities for Localz — 2026-07-28

Scoped to this pass's changed files (Architecture/, CertExams/) checked against Projects/Localz.md.

1. Shopify's row-per-unit + SKIP LOCKED pattern directly answers Localz's booking-concurrency problem

Shopify: Replacing Redis with MySQL for Inventory Reservations solves the exact shape of problem Localz's booking lifecycle has: preventing two consumers from both claiming the same provider time slot. Localz's stack docs (Tech-Stack.md) plan Redis for "availability snapshots" caching alongside Postgres as the system of record for bookings — the same Redis-fast-cache-plus-Postgres-source-of-truth split Shopify explicitly moved away from because it creates a cross-system consistency gap (their case: overselling; Localz's equivalent: double-booking a slot). Worth evaluating whether Localz's bookings/availability tables could use the row-per-slot + SELECT ... FOR UPDATE SKIP LOCKED pattern directly in Postgres instead of leaning on Redis for availability correctness — collapsing "is this slot free" and "did the booking succeed" into one transactional boundary, the same win Shopify measured on Black Friday.

2. Architecture/Fundamentals/rate-limiting-algorithms.md validates and extends Localz's Phase-0 rate-limit plan

Minimal-to-Production-Security-Implementation.md (cited in Localz.md §6) specifies "~20 msg/min per user" chat rate limiting via Redis with no algorithm named. The new Rate Limiting Algorithms note recommends token bucket as the default for exactly this kind of client-facing limit (bursty real traffic, not a hard cap) and flags the distributed-systems trap Localz needs to watch for once it's running multiple app instances: a per-instance in-memory limiter silently multiplies the real limit by instance count unless backed by the shared Redis store Localz already plans to use.

3. Database-sharding-strategies.md names Localz's unresolved multi-city scaling gap

Localz's own contradiction log (Localz.md §9E) flags that NFRs are unquantified and that "handle growth across multiple cities" has no concrete strategy attached. Database Sharding Strategies's geo/tenant sharding section is written for precisely this case (multi-tenant SaaS, data-residency/blast-radius control) and is a natural next reference when Localz's multi-city expansion moves from roadmap item to design decision — worth linking from Localz.md's open-questions section directly.

4. AWS SAA-C03 study material is a direct implementation reference for Localz's own planned AWS phase

Localz's deferred AWS-phase stack (Tech-Stack.md) names RDS/Aurora, ElastiCache, S3+CloudFront, SNS/SQS, EKS — the same service set CertExams/SAA-C03/AWS_Scope.md documents in exam-study depth, including exam-critical sub-features (Aurora Serverless v2 for spiky workloads, DAX for hot-key read latency, NAT Gateway per-AZ resiliency) that map onto specific gaps in Localz's own stack docs (e.g. no stated NAT Gateway topology, no stated Aurora vs. RDS choice). The cert study pass Mihir is already doing is effectively pre-work for Localz's AWS migration — worth flagging concrete SAA-C03 findings back into Localz.md's stack section as they come up, rather than treating the two as unrelated tracks.