diagram.mmd — sequence
Cloud Storage Upload Flow sequence diagram

A cloud storage upload flow describes the sequence of interactions between a client, an application backend, and an object storage service when transferring a file to the cloud — typically using a presigned URL pattern to avoid routing large payloads through the application tier.

The presigned URL approach is the industry standard for uploading directly to object storage (AWS S3, Google Cloud Storage, Azure Blob). Instead of the client sending file bytes to the app server, the backend generates a short-lived signed URL that grants the client temporary write permission to a specific storage path. The client then uploads directly to the storage service, bypassing the application tier entirely. This reduces backend bandwidth costs, eliminates file size limits imposed by application servers, and distributes upload load.

The sequence proceeds as follows:

1. The client requests an upload URL from the backend, providing file metadata (name, size, content type). 2. The backend validates the request — checking authentication, file type allowlists, and size limits — then calls the storage API to generate a presigned PUT URL scoped to a specific object key and expiry window (often 15 minutes). 3. The client receives the URL and PUTs the file bytes directly to the storage endpoint. 4. On completion, the storage service emits an object-created event (or the client notifies the backend directly). 5. The backend records the upload in its database and may trigger downstream processing such as virus scanning, thumbnail generation, or CDN invalidation.

See Object Storage Lifecycle for how objects age through storage tiers after upload, and Cloud IAM Permission Model for the permission grants that make presigned URLs work.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

A presigned URL is a short-lived signed URL generated by the backend that grants a client temporary write permission to a specific object path in cloud storage. The client uploads file bytes directly to the storage service without routing through the application tier, reducing backend bandwidth costs and eliminating application-imposed file size limits.
The backend validates the upload request — checking authentication, file type allowlists, and size limits — before generating the presigned URL. The URL is scoped to a single object key with a short expiry (typically 15 minutes). After upload, the backend records the object reference and may trigger security scanning (e.g., antivirus) before making the file accessible.
Use multipart upload for files larger than 100MB. It splits the file into parallel chunks, improving throughput and allowing resumable uploads if a chunk fails. AWS S3 requires multipart upload for files over 5GB. Most cloud SDKs initiate multipart upload automatically above a configurable threshold.
mermaid
sequenceDiagram participant C as Client participant API as App Backend participant IAM as IAM / Auth participant S3 as Object Storage participant DB as Database participant FN as Processing Function C->>API: POST /uploads/init (filename, size, type) API->>IAM: Verify client token IAM-->>API: Token valid, user ID API->>S3: GeneratePresignedURL(key, TTL=900s) S3-->>API: Presigned PUT URL API-->>C: { uploadUrl, objectKey } C->>S3: PUT file bytes (direct upload) S3-->>C: 200 OK C->>API: POST /uploads/complete (objectKey) API->>S3: HeadObject(objectKey) verify exists S3-->>API: Object metadata confirmed API->>DB: INSERT upload record (userId, key, size) DB-->>API: Record saved API->>FN: Trigger post-upload processing FN-->>API: Processing started API-->>C: 201 Created (uploadId)
Copied to clipboard