F01 — O mapa: cada peça da stack como um posto do restaurante

1. A viagem de um pedido (do toque ao banco)

Quando a cliente toca em Comprar, a tela (Front-end) monta uma comanda em formato JSON e envia pela rede via HTTPS. O porteiro (Caddy) confere o certificado e entrega ao Django.

Lá dentro, o garçom (urls.py) direciona para o cozinheiro (View), o conferente (Serializer) valida os dados, o cozinheiro consulta a despensa (PostgreSQL) via tradutor (ORM) e grava o pedido. Só então volta a resposta '201 Criado' em JSON.

Celular (Next.js) --[HTTPS + JSON]--> Caddy (porteiro)
  --> urls.py (garçom) --> serializer (conferente) --> view (cozinheiro)
  --> ORM (tradutor) --> PostgreSQL (despensa)
  <-- Resposta JSON "201 Criado" <--

2. Onde a analogia do restaurante quebra (muito importante!)

Toda analogia ajuda a lembrar, mas ela não é a coisa real. Na internet, três fenômenos acontecem que não existem num restaurante comum:

1) Mil clientes na mesma última unidade: um restaurante atende uma mesa por vez; na web, duas pessoas clicam em 'Comprar' no mesmo milissegundo. Sem trava no banco, você vende a mesma peça duas vezes.

2) O entregador que toca a campainha duas vezes: o provedor de pagamento pode enviar o mesmo webhook repetido se a rede oscilar. Sem idempotência, você confirma e repassa duas vezes.

3) O cliente pode falsificar a comanda: no navegador, qualquer pessoa pode abrir o DevTools e tentar enviar preço R$ 0,01. O servidor precisa recalcular tudo.