Usuários precisam subir arquivos de até dois gigabytes. Como você projetaria isso de ponta a ponta?

Não passe os bytes pela sua API. Faça o cliente pedir uma URL de upload pré-assinada, subir direto para o armazenamento de objetos com multipart upload para arquivos grandes, e depois avisar o seu serviço, que verifica o objeto e registra os metadados. Valide tipo de conteúdo e limites de tamanho no nível da política, escaneie de forma assíncrona antes de o arquivo ficar utilizável, e gere URLs assinadas de vida curta para download em vez de tornar os objetos públicos.

A primeira decisão é que o arquivo nunca passa pela minha API, porque dois gigabytes através de um handler de requisição prende um worker, custa banda duas vezes e quebra no momento em que uma conexão cai. Então o cliente pede ao meu serviço uma URL de upload pré-assinada, com escopo apertado para uma chave, um tipo de conteúdo e uma expiração curta, e sobe direto para o armazenamento de objetos. Para arquivos desse tamanho eu uso multipart upload, o que me dá retomada, já que uma parte que falhou é repetida em vez do arquivo inteiro. Quando o upload termina o cliente avisa, ou melhor, o armazenamento emite um evento, e meu serviço verifica que o objeto existe e bate com o tamanho esperado antes de gravar os metadados. O arquivo começa num estado pendente e só fica utilizável depois do processamento assíncrono: varredura, checagem do tipo de conteúdo real a partir dos bytes em vez de confiar na extensão, e geração de miniaturas. Downloads passam por uma URL assinada de vida curta emitida após uma checagem de autorização, nunca por um bucket público, que é de onde vem um número surpreendente de vazamentos de dados.