Hermes Wiki
opportunities/2026-08-24-incremental-localz

Incremental Opportunities: Localz (2026-08-24)

Scope: Architecture/Fundamentals/public-key-infrastructure-and-certificates, Tools/AWS_Certificate_Manager, Tools/AWS_CloudHSM, and Architecture/Fundamentals/cell-based-architecture (all new/changed this window) against two gaps already named in Projects/Localz's own docs: the unspecified "encrypted payments" NFR, and the explicitly deferred "multi-city expansion" feature.

Finding 1 — "encrypted payments, secure document storage" (Localz's own NFR) has never been broken into a concrete mechanism, and the PKI/ACM material supplies exactly that

Projects/Localz.md §4 lists "Security — encrypted payments, secure document storage" as a stated non-functional requirement, then immediately flags (same section) that all of Localz's NFRs are "qualitative, not quantified" with no numeric targets and — specific to this finding — no named mechanism for what "encrypted" actually means in transit vs. at rest vs. for which specific data class (KYC documents, payment tokens, chat media).

Architecture/Fundamentals/public-key-infrastructure-and-certificates draws the exact distinction Localz's stack needs to make concrete: public CA, low-friction, automated (the right fit for the customer-facing app's own TLS — Tools/AWS_Certificate_Manager against an ALB/CloudFront distribution, zero operational burden) versus private/internal CA (the right fit only once service-to-service mTLS between Localz's own FastAPI modules becomes worth the root-key-custody overhead — not needed at MVP scale, per the note's own "don't stand up a private CA for a small system... until service-to-service auth is a real, recurring problem" guidance). Localz's current modular-monolith architecture (single FastAPI codebase, no service mesh yet) means the public-CA path via ACM is the right scope today — the note explicitly warns against over-engineering the smaller case.

Separately, Tools/AWS_CloudHSM's CertExams-documented decision rule (CloudHSM's single-tenant FIPS 140-2 Level 3 hardware vs. KMS's multi-tenant Customer Managed Keys) is directly relevant to the "secure document storage" half of the NFR: Localz stores KYC ID documents and signed rental agreements in S3, and the CertExams material's rule ("if the question specifies dedicated, single-tenant hardware, the answer is CloudHSM; if it just needs customer control over key policies without dedicated hardware, the answer is KMS") maps cleanly onto Localz's actual scale — a local-marketplace startup's KYC documents need encryption-at-rest with customer-controlled keys (S3 + KMS CMKs), not CloudHSM's dedicated-hardware tier, which is overkill outside heavily regulated banking/healthcare contexts.

Concrete next step: replace the NFR bullet "encrypted payments, secure document storage" with two explicit, scoped decisions before AWS-phase provisioning: (1) public ACM certificate on the customer-facing ALB/CloudFront, no private CA until a service mesh exists; (2) S3 + KMS CMK (not CloudHSM) for KYC documents and signed agreements, with the CMK's key policy scoped to the specific IAM roles that need document access (booking-verification service, support staff with an audit-logged access path) — not a blanket S3-bucket-level encryption flag with no key-policy granularity.

Finding 2 — cell-based architecture is the design pattern Localz's own "multi-city expansion" deferral is quietly asking for

Projects/Localz.md §"deferred to Phase 2+" explicitly names "multi-city expansion" alongside subscriptions, coupons, and marketplace ads — treated as a feature-flag-level deferral, not an architecture decision. But multi-city is structurally different from the other deferred items: subscriptions and coupons are additive features bolted onto the existing single-region monolith, while multi-city expansion is the first point where Localz's "one shared backend serving everyone" assumption gets tested by a genuinely partitionable workload — each city's bookings, providers, and search index are naturally independent of every other city's.

Architecture/Fundamentals/cell-based-architecture names precisely this shape as the strong fit: "use when you already have a natural partition key (tenant ID, account ID, region) that cleanly maps requests to cells without cross-cell chatter." A Markham cell going down shouldn't take a hypothetical Mississauga cell with it, and Localz's own booking/chat/search data has almost no legitimate cross-city query need (a consumer books a plumber in their own city, not searches nationally) — meaning the "poor fit for workloads dominated by cross-partition operations" caveat doesn't bite here the way it would for, say, a national analytics rollup.

Concrete next step: when multi-city expansion moves from "deferred" to "planned," don't default to "scale the existing single-region stack bigger" — evaluate a per-city (or per-metro) cell boundary at the routing layer (a thin, dumb request router mapping a request's declared or inferred city to its home cell) before the second city launches, not after a first cross-city incident forces the question. This is a decision that's cheap to design in from city #2 and expensive to retrofit once city #5's outage has already taken out city #1 through a shared database or shared cache — the same "cheap now, expensive later" pattern already flagged for Localz's RDS encryption-at-rest decision in the earlier RDS encryption synthesis note.

Hermes Wiki