Se a vaga pede SQL / PostgreSQL, vale saber responder isso. A resposta está em inglês de propósito, porque é assim que você vai precisar falar.
How much one running transaction can SEE of another. From weakest to strongest:
Read Uncommitted → allows dirty reads (seeing data another transaction hasn't committed yet) in the SQL standard. Postgres runs it as Read Committed, so dirty reads never happen there.
Read Committed (Postgres DEFAULT) → no dirty reads, but re-reading the same row inside the transaction can return different values (non-repeatable read), and re-running a query can return NEW rows (phantom read).
Repeatable Read → PostgreSQL reads a snapshot established by the first non-transaction-control statement, plus the transaction's own writes. Concurrent commits do not introduce non-repeatable or phantom reads. Write skew can still occur: two transactions read a shared invariant, change different rows, and jointly violate it. Serializable prevents such committed anomalies. An appropriate constraint or locking protocol can also protect a specific invariant at a weaker isolation level.
Serializable → committed transactions behave as if they ran one at a time. PostgreSQL monitors conflicts, adding overhead and sometimes aborting transactions that the application must retry. The performance cost depends on workload. It is not always the slowest option.
Say: "I identify the invariant and the concurrent operations first, then choose constraints, atomic updates, locks, or Serializable with whole-transaction retries." A money transfer does not automatically require Serializable.
Source: PostgreSQL transaction isolation.
Ler é o primeiro passo. No app, essa pergunta vira flashcard com repetição espaçada, e o módulo tem quiz e simulado para testar o que ficou.
Treinar essa pergunta no app