A job inserts an order into `orders` and reduces stock in `inventory` on Databricks. If the second step fails, the tables disagree. How do you make both changes happen together or not at all?

Wrap the statements in a multi-statement transaction, generally available on Databricks since October 2026: BEGIN ATOMIC ... END commits every statement together, and any error rolls them all back. It needs the tables to be Unity Catalog managed Delta or Iceberg tables with catalog commits. On older setups, the fallback is to make the job safe to re-run: write both changes in one table, or record a batch ID and make each step idempotent.

1. The transaction

BEGIN ATOMIC
  INSERT INTO shop.sales.orders (order_id, sku, qty) VALUES (1042, 'TEA-01', 3);

  UPDATE shop.sales.inventory SET on_hand = on_hand - 3 WHERE sku = 'TEA-01';
END;

If the update fails, the insert is undone too. To reject on a business rule, raise an error with SIGNAL inside the block.

2. What it requires and allows

3. Concurrency

There are no locks. Each transaction reads from a snapshot and checks for conflicts at commit; if another writer changed the same data first, the commit fails and the job must retry. So keep transactions short, and make the retry part of the job.

4. Before this existed

Each statement was its own transaction on one table. Teams worked around it by:

• Re-running the whole job safely: a MERGE keyed on order_id instead of a blind insert, so a retry does not duplicate. See Idempotent Pipelines and Exactly-Once.
• Writing an event table first and deriving both tables from it.
• Checking with a reconciliation query after each run.

Those remain good habits; the transaction removes the window where a reader sees half the change. See ACID Transactions and Delta Lake.

What interviewers want: BEGIN ATOMIC with automatic rollback, the managed-table and catalog-commit requirement, DDL outside, optimistic concurrency and retries, and the idempotent fallback for platforms or tables without it.