Object storage vs databases, and S3 architecture

S3's actual architecture (worth knowing because it explains the constraints): objects are keyed; a partition map assigns key-prefixes to storage nodes (the reason prefix throughput limits exist — a hot prefix concentrates on one node); GET/PUT are object-granular; durability comes from replication/erasure coding within a region (11 nines); consistency is read-after-write per object (strong since Dec 2020; list-after-write still eventually consistent). It's not a file system: no partial writes, no locks, no queries — cheap, durable, infinitely-wide storage with an HTTP API.

The decision rule: object storage for blobs, databases for state. The classic mistakes: storing files in Postgres (TOAST bloat, buffer pollution, backup drag — though small files can be fine) vs. storing truth in S3 (no transactions, no constraint — your zoth policies must never live there).

Cost/latency shaping — the S3 request patterns that matter:

• Multipart upload for big objects (parallel parts, retry only failed parts) — the pattern behind traverse's streaming recon dump (writes chunks, then rename/complete).
• Range GETs for partial reads (video seek, tailing logs).
• Prefix listing (ListObjectsV2) is O(prefix) — not a query, a scan.
• Lifecycle rules to cheap storage classes (IA/Glacier) — the retention answer (Day 87's topic).
• Cross-region replication for DR — traverse's absence of it for backups is "backups live in a different region from the primary" (already region-separated risk), a defensible mini-DR answer.

Your actual S3 usage (traverse) — correct, claimable:

1. WAL archive (us-east-1, dedicated bucket/creds): object-per-WAL-segment, immutable, lifecycle-friendly. The canonical DB+object-storage pattern: database for state, object storage for the change log.
2. Career applications: resume files → key applications/{id}/{filename}, in the careers bucket (ap-south-1) — user blobs never touch the database; the DB stores the key + metadata. Plus signed/limited access paths. Two buckets = two blast radii (Day 34) — also the "tenant separation" idea applied at the storage layer.
3. Recon dumps: the streaming write — .partial file then atomic rename (a local-file idiom, but the same all-or-nothing visibility principle as S3 multipart-complete: readers only ever see complete objects).

The content-addressing idea (from your topic list, one paragraph): key objects by SHA256(content) → dedup for free, integrity check on read, immutability natural (same content = same key). Where yours could use it: recon dumps (dedupe identical capture bundles) and WAL segments (integrity verification at restore). Where it doesn't fit: user-visible keys (career applications need ownership/permissions keyed by identity, not content).

Zoth's object-storage absence is itself the answer: no blobs in the domain (policies are rows, documents are text-embedded). The resume-relevant sentence: "I know exactly what S3 would buy zoth — exported audit archives per tenant, lifecycle to Glacier for retention — and chose not to add it at demo scale."