Blob storage and CDNs
Big files do not belong on your servers. Cut them into chunks named by their hash, write the chunks first and the manifest last, and let edge caches near the reader send the bytes, because a name whose bytes never change can be cached forever.
Why not store images in the database?
A database is built for many small rows that change, read by key and by index. A 300 KB photo in a row makes every backup, replica and cache of that table carry the bytes, and the database box ends up spending its network card on sending pictures. Keep the photo in a blob store and keep a row with its name, owner and size. The row stays small and fast; the bytes go out through a CDN that never touches the database.
What does content-addressed mean?
A chunk is stored under the hash of its own bytes rather than under a name someone chose. Two identical chunks get the same name, so they are stored once, and the name doubles as a checksum a reader can verify. Because the bytes behind a hash can never change, any cache anywhere may keep the chunk forever without asking whether it is still current.
How does a CDN know when an image changed?
The reliable answer is that it does not have to. Give every version of an object a new URL, for example with a hash or a version number in the path, and send it with a long max-age. Changing the picture means publishing a new URL, and the old one stays correct forever. Purging a CDN by URL is possible, but it takes time to reach every edge, so treat it as a repair tool rather than the way updates work.
Why are uploads split into parts?
A 5 GB file over a 20 Mbit/s home uplink takes about 33 minutes, and a connection that drops halfway through a single request loses everything sent so far. With numbered parts of a few megabytes, a drop costs one part, the client asks which parts are missing, and it sends only those. Parts can also go over several connections at once and arrive in any order, because the manifest is built by part number when the upload completes.
Why are signed URLs used instead of sending files through the API?
A signed URL lets the client talk to the blob store or the CDN directly while your API decides who may do so. The API checks the user, then returns a URL that carries the path, an expiry time and an HMAC signature over both. The store recomputes the signature and refuses anything edited or expired. The bytes never pass through your application servers, which then only handle small metadata requests.