## Design a Cloud-Provider Upload Adapter Design a small class layer that lets a backend initiate direct uploads through different cloud storage providers without exposing provider-specific request shapes to the rest of the application. Extend the design with a server acknowledgement path that synchronizes backend state after the client reports a successful upload. ### Part 1 — Define the Stable Application Interface Specify the application-facing request, result, provider interface, and upload record. Keep only behavior common to every supported provider in the shared abstraction. #### What This Part Should Cover - An `UploadRequest` with object identity, declared metadata, expiry, and policy constraints. - A normalized `UploadTarget` carrying URL or session data, method, required headers, provider reference, and expiry. - An `UploadProvider` operation for creating the target and another for inspecting completion. - Dependency injection or configuration that selects a provider without conditionals throughout business code. ```hint Abstract the capability, not the vendor vocabulary The application needs a safe way to initiate and verify an upload; provider-only options can remain inside the adapter. ``` ### Part 2 — Implement Provider Adapters Explain how each adapter translates the normalized contract into its provider SDK, credentials, errors, and supported capability set. #### What This Part Should Cover - Provider-specific clients and credentials confined to one adapter. - Explicit handling when a requested constraint is unsupported. - A normalized error taxonomy for validation, retryable failures, authorization, and unknown outcomes. - No logging of signed URLs, credentials, or sensitive headers. ```hint Do not hide missing guarantees An adapter should reject an unsupported integrity or size constraint rather than return a target that appears to enforce it. ``` ### Part 3 — Acknowledge and Finalize Uploads Design `acknowledgeUpload(uploadId)` for the point after a client believes the direct upload succeeded. Make the operation idempotent and safe under duplicate or dishonest requests. #### What This Part Should Cover - Lookup of the backend-owned upload record and its selected provider reference. - Provider inspection before marking the object uploaded. - Conditional state transitions that converge with provider callbacks. - Stable results for duplicate acknowledgements and explicit failure reasons. ```hint Verify through the adapter The client acknowledgement chooses which upload to inspect; it must not supply the authoritative object location or completion status. ``` ### Part 4 — Test and Evolve the Abstraction Describe unit, contract, and integration tests and how a new provider is added without changing upload business rules. #### What This Part Should Cover - Fake adapters for application-state tests and contract tests shared by every provider. - Cases for expiry, required headers, duplicate acknowledgement, timeouts, and unknown provider outcomes. - Capability discovery or configuration validation at startup. - Versioning when the shared interface gains an optional feature such as multipart upload. ```hint Test behavior shared by every adapter A provider implementation is interchangeable only if the same contract suite gives the same application-level result. ``` ### What a Strong Answer Covers - A narrow normalized interface with provider-specific details contained behind adapters. - Explicit capability and error semantics rather than a lowest-common-denominator illusion. - Backend verification and idempotent acknowledgement before durable completion. - Shared contract tests, secure logging boundaries, and an extension path for new providers. ### Follow-up Questions 1. Where should multipart-upload differences live if only some providers support them? 2. How would you rotate provider credentials without rebuilding every caller? 3. What state should an acknowledgement return after provider inspection times out? 4. How would you migrate in-progress uploads while changing the default provider?