ProductImage = intent (with states , intial state pending)+ business semantics

ImageContent = verified binary reality

phase 1 init (pending state record not idempotent at db storage level,gc pending rows later)-

client —> server

call init - store pending intent in prod_img , content id null as no binary exists.

only product image intent is recorded with nulls for later binding with actual img .

respond to client with prod img public id as an anchor to used by client for upload call .

phase 2 upload (client to cloud)

upload via a unique prod img public id for a particular file so any retries or duplicate requests don’t save new files for same image content . otherwise it would get complex to gc duplicates in cloud later to save space.

phase 3 (cloud — server) webhokk , we can also keep a status endpoint on server side to check status in case of network issues for long time etc .

send status of upload to server so that we update state and save state of url or storage key etc and bind img content to prod image .

batch errors — errors solvable by client should be appended to errors per each item and also record successes and respond to client . For errors like not fixable by client raise them and let be gone to central stacktracer .