DDIA Learn — Designing Data-Intensive Applications

A transaction is a logical unit of work that succeeds or fails as a whole. ACID properties define the promise, but real systems implement them with varying strictness — especially in distributed settings.

Consistency in ACID

Unlike the other three properties, consistency depends on application-defined invariants (e.g., account balance >= 0). The database provides tools; the application defines the rules.

In practice

A bank transfer in PostgreSQL wraps debit and credit in BEGIN/COMMIT — both rows update or neither does. Stripe uses idempotency keys with PostgreSQL to make retried API calls safe. MongoDB multi-document transactions work across collections but cost more than single-document atomic writes in DynamoDB.

Stripe at scale

A payment capture debits the customer, records the charge, and updates the merchant balance in one PostgreSQL transaction — partial failure rolls back all three writes.

typescript — Multi-step booking transaction

// Airbnb booking: debit guest + credit host atomically
await prisma.$transaction(async (tx) => {
  const booking = await tx.booking.create({
    data: { listingId, guestId, checkIn, checkOut },
  });
  await tx.payment.create({
    data: { bookingId: booking.id, amountCents, status: "CAPTURED" },
  });
  await tx.availability.update({
    where: { listingId_date: { listingId, date: checkIn } },
    data: { available: false },
  });
});

The Slippery Concept of a Transaction