One Product, Hundreds of Restaurants

A multi-tenant restaurant platform has an unusual entry point: the URL is not merely an address. It identifies the business whose menu, visual identity, ordering rules, and data the guest expects to see. In Sofreh, a request may arrive through a platform subdomain or a restaurant's own domain, but both must resolve to the same internal tenant context.

The routing layer therefore does more than match paths. It normalizes the host, rejects unknown hosts, resolves active custom domains, and rewrites valid tenant traffic to the internal public-menu surface. The browser sees a restaurant-specific address; the application receives an explicit, server-resolved establishment identity. That translation keeps tenant discovery at the edge instead of scattering hostname logic throughout pages and components.

Accepting a hostname in a settings form is the easy part. Trusting it is the real feature. Sofreh gives every domain request a unique verification token and asks the owner to publish it as a DNS TXT record under _sofreh. Routing is checked separately through CNAME or configured edge addresses. Ownership and reachability are different facts, so the system refuses to collapse them into one green checkmark.

The domain moves through explicit states: pending DNS, pending certificate, active, failed, or pending deletion. Certificate jobs use the record's status and version to avoid applying stale work after a restaurant changes its configuration. The UI polls only while infrastructure work is active, turning a slow external process into a legible product experience without pretending DNS is instantaneous.

Custom domains are subscription-gated, which creates a second lifecycle most implementations ignore: what happens when the entitlement disappears? Continuing to serve the domain leaks a paid capability. Deleting it immediately can leave certificate state and reverse-proxy configuration out of sync.

Sofreh reconciles active domains against current entitlements and queues safe teardown when access is lost. During removal, new routing stops while certificate cleanup completes as managed work. The platform subdomain remains available, so a billing transition does not erase the restaurant's public presence. This is a useful rule for every SaaS feature with external infrastructure: provisioning and deprovisioning deserve equal design effort.

The strongest tenant isolation does not come from reminding every developer to remember a filter. It comes from shaping the architecture so the normal path already carries the establishment identifier into services and repositories. Routes authenticate and resolve context; services own business rules; repositories perform scoped persistence. Each layer has one reason to know the tenant.

A tenant boundary should be structural, not ceremonial.

The practical test is simple: how much unusual code is required to access another tenant's data? If bypassing the boundary is easier than following it, the architecture is relying on discipline. Sofreh's design goal is the opposite—the secure path is the ordinary path, and cross-tenant behavior must be conspicuous enough to review deliberately.