When you import food into a country, it doesn't go straight to supermarket shelves. It sits in a customs quarantine while inspectors check it for pests and contamination. Only after it clears does it enter the supply chain. Until then, it's treated as guilty until proven safe.
The Quarantine pattern applies the same discipline to digital assets you receive from outside — uploads from partners, packages from a third-party feed, container images from an external registry. Instead of trusting them the moment they arrive, you park them somewhere isolated, run your checks, and only then let the rest of your system touch them.
The problem
Assets that originate outside your control are a liability. A vendor publishes a data file with a corrupt schema. A user uploads a document carrying malware. An upstream image bundles a vulnerable library. If your system reads from a shared, trusted location the instant new content shows up, every one of these problems becomes your problem the moment it lands.
The core mistake is conflating "published" with "trusted." Just because a file exists in a bucket your services can read doesn't mean it's safe to consume. Without a deliberate gate, the first thing that ever validates the asset is your production code — and by then it's already too late.
External publisherAn outside party you can't fully trust — a partner feed, a user upload, an upstream registry. Some of what it publishes is corrupt or malicious.
Trusted store (no vetting)Without a quarantine zone, assets land straight into the location your services read from. 'Published' is wrongly treated as 'trusted'.
Production servicesConsume the asset immediately. The first thing that ever validates it is your production code — and by then a poisoned artifact is already live.
How it works
You introduce two distinct locations. New external assets are published only to a quarantine store — an isolated bucket, registry, or folder that no consumer reads from. Landing there triggers a validator: an automated process that runs whatever checks the asset type demands — virus scans, schema and format validation, signature verification, policy rules.
If every check passes, the validator promotes the asset by copying or moving it into the trusted store, where your real services finally read it. If anything fails, the asset stays put, gets quarantined or deleted, and an alert fires. The trusted store therefore only ever contains vetted content. The diagram below traces an asset from arrival, through scanning, to promotion into the location your system actually relies on.
- Quarantine storeAn isolated location where new external assets land first. No consumer reads from here, so an unvetted file can't reach production.
- ValidatorRuns the checks the asset needs — malware scan, schema and format validation, signature verification — and decides pass or fail.
- Trusted storeHolds only assets that passed every check. The validator is the sole thing allowed to write here.
Make the trusted store unwriteable except by the promoter. The pattern only holds if there's no back door — if any process can write straight into the trusted location, the quarantine becomes theatre. Lock permissions so the validator is the only thing that can move an asset across the boundary.
When to use it
Quarantine earns its keep whenever you ingest assets you didn't author and can't fully trust: user uploads, partner data drops, third-party packages, externally built images. It complements a gatekeeper, which screens incoming requests, by doing the same job for incoming content. When the publisher is an external party, pairing it with federated identity lets you record exactly who submitted what, so a rejected asset is traceable back to its source.
The trade-off is latency and an extra moving part: assets aren't usable the instant they arrive, and you now run and monitor a validation pipeline. For content you generate yourself in a trusted pipeline, that overhead buys little. But for anything crossing your trust boundary from the outside, a quarantine zone is a cheap way to keep one bad upload from becoming a production incident.