Azure Blob Storage

Most Azure Blob Storage work we're brought into starts with a margin question, not a technical one: why did last month's landed cost run high, or why did a container of return credits sit unprocessed for ten days. We start by pulling the containers apart by purpose: which hold inbound feeds, which hold outbound exports, which are dead drops left by a project that moved on. A storage account with a SAS token for every partner, never rotated, tells you who built this in a hurry. Before we recommend anything, we map what's actually landing, how often, and which team would notice if it stopped. That diagnostic is what turns into a scoped build, not a guess at architecture.

Blob Storage doesn't own anything. It's a drop point, which is exactly the problem when two systems both assume it's authoritative. Ownership and handoff redesign starts with naming, container by container, which system writes first and which system only reads: a landed cost file that ERP should treat as read-only, a warehouse feed written by a 3PL that nobody else touches. The costly version of this gets skipped: a marketing team drops a product feed into the same container a pricing job reads from, and a promotional price survives two weeks after the campaign ends because nobody agreed who could overwrite what.

Ownership map: - Containers: who writes, who reads, who deletes - SAS tokens: scoped by permission and expiry, not shared as a master key - Schema changes: owned by the producing system, versioned, never silent

Get this wrong and the integration looks healthy right up until a stale file gets read as current.

Point-to-point blob integrations age badly. Each new partner means another SAS token, another schema to track, another CSV someone's quietly uploading by hand to cover a gap nobody fixed. That manual step is a common tell: a named person pulling a file every morning is doing the work the architecture should be doing.

Patchworks gives this a proper home. Containers become managed connections rather than one-off scripts, schema changes are caught before they corrupt a feed, and onboarding a new warehouse or marketplace takes days of configuration, not a rebuild. Cost stays predictable because adding a channel doesn't mean adding a bespoke integration to maintain.

Cogent² runs this with AI-assisted monitoring watching arrival patterns and schema drift across every container, flagging what a human reviewer would otherwise catch days late. We're operators who use that tooling well, not a vendor selling the tooling itself.

Monitoring a blob-based feed means watching for absence as much as error. A file that doesn't arrive by six in the morning looks identical to a quiet night, until three days later someone in finance asks why landed costs haven't updated. We set alerting on file arrival windows, row counts against a rolling average, and schema drift on column names and types, because a renamed column passes silently and a mapped field starts receiving nulls.

Where this breaks: a partner renames a field in their export, the consuming system maps it to the old name, and for two weeks every stock update for that supplier writes zero. Nobody notices because the job runs green. It only surfaces at a stocktake, or when a customer orders something the warehouse has already sold out of.

Whoever owns a container needs a one-page runbook: what lands, how often, what a stale file looks like, who to call. We write these short on purpose, because long SOPs don't get read at seven in the morning when a feed is missing. Named escalation matters more than documentation volume: one person for SAS token rotation, one for schema questions on the producing side, one for the consuming system. Without named owners, a missing file becomes a group chat instead of a fix.

After go-live we stay on the containers through the first peak, because that's when file volumes jump and a feed sized for a normal Tuesday starts arriving in batches the trigger wasn't built to handle. Hypercare means watching arrival timing, queue depth and retry counts daily, not waiting for a complaint to surface the gap. Escalation during peak needs a shorter path than the standard runbook: a direct line to whoever can rotate a SAS token or bump a trigger's concurrency in the middle of the night, not a ticket queue. Once the pattern holds through one full peak, we step back to a lighter cadence, but the runbooks and alerts stay in place for whoever's on call next.