Deployment & Operational

A deployment stamp is a complete, self-contained copy of an app and its database, deployed once per group of customers. Instead of building one giant system for everyone, you stamp out many identical smaller copies, each handling its own slice of users.

If settings are baked into the image, you need a different image per environment, and changing a value means rebuilding and redeploying. An external store keeps those settings outside the artifact so one image runs everywhere, each instance just reads its own values from the store at startup.

A feature flag is an on/off switch in code that lets you turn a feature on for some or all users without redeploying. It separates 'the code is live on servers' from 'users can see/use it.'

A gatekeeper is a stripped-down front-door server that checks and cleans every incoming request before it's allowed through, so bad or malformed input never touches the real backend systems directly.

It solves slow response times for far-away users and the risk of one data center outage taking the whole app down. By putting a full copy of the app and its data close to users everywhere, requests are answered nearby (fast) and if one region fails, the others keep working.

A sidecar is a helper container that runs right next to your app in the same pod, sharing its network and storage, so it can add things like logging or security without changing the app's code.

Static files never change per request, so storing them in cheap storage and letting a CDN cache copies close to users is faster and cheaper than making app servers hand out those same bytes over and over.

When several apps share one machine, a greedy or misbehaving one can hog CPU, memory, or disk and slow down the others — that's a noisy neighbor. Limits and quotas on each app's resource use stop that from happening.

A stamp usually bundles the app servers AND their own database (plus caches/queues) together as one unit. If the database were shared across stamps, you wouldn't actually raise your capacity ceiling or contain failures — you'd just have duplicated app servers hitting the same bottleneck.

The store keeps a general default config, then more specific layers (per environment, per instance) that only override the keys they care about. At startup the instance merges these layers, most-specific-wins, instead of one giant file duplicating every setting per environment.

Not all flags are used the same way: some hide a feature until it's ready (release), some let you turn something off in an emergency (ops), some split traffic to compare two versions (experiment), and some control who is allowed to use a feature long-term (permission). Because they serve different purposes, some should be deleted quickly and others are meant to live forever.

The system turns each user's ID into a number (via a hash) and checks if that number falls under the 10% cutoff. Because the same ID always hashes to the same number, the same user always lands on the same side of the line, so they don't flicker between old and new experience.

Splitting the job into two separate machines means the one attackers can reach never holds the passwords to the real database, so even if it's hacked, the valuable stuff stays locked up on a different machine.

A smart DNS or traffic-routing service looks at where the request is coming from and sends it to the closest healthy region. If that region's health checks start failing, the router stops sending it traffic and reroutes everyone to the remaining regions instead.

An ambassador is a small proxy sitting next to your app that handles outgoing calls for it - retries, TLS, finding the right server - so the app just talks to 'localhost' and the proxy does the hard networking work.

Cache-Control tells browsers and the CDN how long to keep a file before checking again. Putting a unique hash in the filename means a changed file gets a brand-new URL, so you can cache old URLs forever without ever serving stale content under a new version.

Don't share a machine when one service needs strong security/compliance isolation, has very different scaling needs, or when a shared outage would be unacceptable — the risk of one dragging down or exposing the other outweighs the savings.

Instead of deploying, monitoring, and patching one system, you now do it N times — once per stamp. Teams manage this by automating stamp creation, rolling changes out gradually (a few stamps at a time) instead of all at once, and building fleet-wide dashboards so N stamps don't mean N times the manual monitoring effort.

Poll-based: each instance periodically asks the store 'anything new?'. Push-based: the store actively notifies instances (via a watch or event) when something changes. At fleet scale, the risk is instances applying the change at different times, so the fleet briefly runs inconsistent config.

If the 'safe' front-door server still ends up with real access to the backend — through a shared credential, an overly open internal channel, or the backend blindly trusting whatever it sends — a hack of the front door is just as bad as before, even though the pattern looks correctly set up.

You now have to keep three copies of everything in sync - code, config, database schema - and every release has to be rolled out carefully across all three without breaking anyone. If your users are all in one place anyway, or the product is small, that extra work often isn't worth the benefit.

The sidecars (data plane) are the many small proxies that actually move traffic; the control plane is one central brain that tells all of them what rules to follow, so you configure once instead of touching every proxy separately.

One workload mostly waits on disk or network while the other mostly crunches numbers, so together they use the machine's CPU at different moments instead of both fighting over it at the same time.

A control service picks a stamp for the new tenant — usually whichever stamp has room left, or a dedicated one if required. When a stamp fills up, the platform either stops assigning new tenants to it, provisions a brand-new stamp, or migrates some existing tenants off it to free space.

You pay extra delay per request and more servers to manage and patch; in return, a hacked front-door server can't reach the real database, so break-ins stay small and contained.

Geodes are all interchangeable copies that can each serve any user, so if one goes down the others just pick up its traffic. Stamps are separate, isolated slices that each own their own specific customers, so if one stamp goes down, only that stamp's customers are affected, and nobody else can serve them until it's back.

Each stamp has its own app servers and database, so a crash, bad deploy, or one tenant's heavy load on one stamp stays contained to that stamp's tenants. But shared pieces outside the stamps — like a shared login service or the control plane — can still take down every stamp at once if they fail.

Ordinary settings like timeouts are fine as plain text anyone can read. Secrets need to be encrypted, tightly access-controlled, auditable, and rotatable, so they're kept in a separate secrets manager that adds encryption-at-rest, fine-grained access policies, audit logs, and automatic rotation - things a plain config store usually lacks.

Every flag adds an extra code path, and it's easy to add a flag but nobody's job to remove it later, so old, forgotten flags pile up. Teams fight this with expiry dates, dashboards showing stale flags, and treating flag removal as a normal, required step of finishing a feature.