Amazon S3

Before Cogent² touches a bucket, we ask who actually depends on it. A retailer's S3 estate usually accumulates sideways: a developer wires an export here, a reporting contractor adds a folder there, and within two years nobody can say which prefix feeds finance and which one is dead. We map every producer and consumer against each prefix, not just the bucket policy, because that is where ownership actually lives.

Where a feed into S3 stops silently and a nightly report still runs on stale data, the first ticket raised is a finance query, not an engineering one. That diagnostic sets the scope and cost of the fix, not a guess.

The question that decides whether an S3 bucket is an asset or a liability is not technical. It is ownership. S3 holds no inventory and no order state of its own; it only stores objects that other systems write and read, which means every prefix needs a declared owner before anything else is built on top of it.

Ownership line: - Order and stock exports: owned by ERP or ecommerce, never by whichever job happened to be plugged in first. - Image and asset folders: owned by the catalogue system, with S3 acting as storage, not as the record. - Carrier manifests and finance exports: owned by finance, with naming conventions fixed before the first file lands.

Because 'folders' in S3 are just key prefixes rather than real directories, two systems can write to what looks like the same location and quietly overwrite each other's files. That single design fault causes more missing-data tickets than any API failure we have diagnosed.

S3 has no native SFTP. It only speaks a REST API, and 'folders' are key prefixes rather than directories, which catches out any partner or legacy tool that assumes a mounted filesystem. Where a carrier or marketplace feed can only speak SFTP, the fix is AWS Transfer Family in front of the bucket, not a workaround bolted onto the retailer's own code.

Patchworks sits above that layer as the place where retries, validation and alerting actually happen, rather than being rebuilt inside every connector that touches the bucket. That matters more as channels and warehouses get added, because a retailer adding its third marketplace should not need a new point-to-point job for every prefix it touches. Cogent² operates that layer as expert integrators, using AI-assisted delivery to review exception patterns faster than a person reading logs line by line, never as an AI-first replacement for the judgement that decides what a prefix is actually for.

Volumes that looked stable in testing rarely stay that way once a marketplace or a third warehouse starts writing to the same bucket. Monitoring here is not about the bucket being 'up'. S3 is almost always up. It is about whether the expected object count for a given prefix on a given day matches what actually landed, and whether a consumer job picked every one of them up.

Operator note: the most useful alert on an S3 integration is a count mismatch, not an error code. A feed that writes zero objects instead of the usual thousand throws no exception anywhere, but it is the one that produces a stock discrepancy a finance team only finds at period close. Catching that gap before the close, not after, is the entire point of watching the prefix rather than the pipe.

Enablement here is short and specific: a one-page map of which prefix belongs to which system, who gets paged when object counts drop, and who is allowed to delete a key. Most teams already have the technical runbook; what they lack is a named owner per prefix, so escalation defaults to whoever is online. We hand over that ownership list alongside the standard SOP, not instead of it, because a bucket with no named owner is the fastest way to end up with a manual export nobody can explain.

Hypercare after go-live is about watching prefixes under real load, particularly around peak image uploads and promotional feed spikes, when object volumes jump without any change to the code writing them. A listing job tuned for a thousand keys a day behaves differently at ten thousand, and that difference only shows up under pressure.

Past hypercare, support means owning the escalation when a partner feed into or out of a bucket changes shape without notice. That is common with marketplace and carrier integrations, where a payload format shift can go unannounced and a retailer's fulfilment desk finds out through a spike in failed exports rather than a release note.