Transactions and Consistency Basics
Learn how transactions, consistency, idempotency, and eventual consistency protect correctness in production systems.
What you will be able to do
Consistency is about what users and systems are allowed to believe after data changes. Transactions are one tool for protecting correctness when multiple changes must succeed or fail together.
Why Consistency Matters
Not every piece of data needs immediate consistency. But some flows, such as payment, inventory, account balance, and certificate issuance, can damage trust if they become contradictory.
| Flow | Consistency need | Reason |
|---|---|---|
| Payment capture | Strong correctness | Do not charge twice or lose confirmed payment. |
| Inventory checkout | Strong enough to prevent oversell | Business correctness. |
| Unread badge count | Eventual consistency usually okay | A short delay is acceptable. |
| Analytics dashboard | Eventual consistency okay | Reporting can lag. |
| Certificate issuance | Strong enough to prove eligibility | Credential trust and audit. |
Transactions in Plain Language
A transaction groups changes so they are committed together or rolled back together. This is useful when partial success would create invalid business state.
| Transaction property | Beginner meaning | Example |
|---|---|---|
| Atomicity | All changes happen or none happen | Create order and order items together. |
| Consistency | Rules remain valid | Order total matches item totals. |
| Isolation | Concurrent actions do not corrupt each other | Two checkouts do not reserve the same last item. |
| Durability | Committed data survives failure | Confirmed payment receipt remains after crash. |
Scenario: Course Certificate Issuance
SkillSkore should issue a certificate only when the user completes required modules and passes assessments. If scoring, eligibility, and certificate issuance are inconsistent, the product loses trust.
| Step | Correctness concern | Design response |
|---|---|---|
| Assessment submitted | Attempt should not be recorded twice | Use idempotency key or unique attempt ID. |
| Score calculated | Score must match submitted answers and rubric | Store immutable answer snapshot and score version. |
| Module score updated | Should reflect latest valid attempt policy | Transactional update or deterministic recalculation. |
| Certificate issued | Should happen once when eligible | Unique constraint on userId + courseId certificate. |
| Notification sent | Should not block certificate truth | Async event after durable issuance. |
Eventual Consistency
Eventual consistency means different parts of the system may temporarily disagree, but they should converge. It is acceptable when the product can tolerate delay and users are not misled.
| Eventually consistent data | Why acceptable | Guardrail |
|---|---|---|
| Dashboard progress percentage | Can update seconds later | Show last updated time if needed. |
| Email sent status | Delivery depends on provider | Track pending, sent, failed states. |
| Search index | New content may appear shortly after write | Do not use search index as source of truth. |
| Analytics counters | Business reports can lag | Define freshness expectations. |
Design principle
Use strong consistency where contradiction breaks trust. Use eventual consistency where temporary delay is acceptable and the source of truth is clear.
Patterns for Correctness
| Pattern | Use when | Example |
|---|---|---|
| Unique constraint | Prevent duplicates | One certificate per user/course. |
| Idempotency key | Clients or workers may retry | Retry assessment submission safely. |
| Outbox pattern | Need database write and event publishing | Store CertificateIssued event with certificate transaction. |
| Compensation | Need to undo later step | Refund payment if order fulfillment cannot proceed. |
| Versioning | Avoid stale updates | Only update profile if version matches. |
Cloud Consistency Options
| Need | AWS | GCP | Azure |
|---|---|---|---|
| Relational transactions | RDS/Aurora | Cloud SQL/Spanner | Azure SQL |
| Conditional writes | DynamoDB conditional writes | Firestore transactions/Spanner | Cosmos DB conditional writes/ETags |
| Event/outbox processing | DynamoDB streams/EventBridge/SQS | Pub/Sub/Cloud Tasks | Event Grid/Service Bus |
| Strong global relational model | Aurora Global Database trade-offs | Spanner | Cosmos DB/Azure SQL with region trade-offs |
| Audit logs | CloudTrail/S3 | Cloud Audit Logs/Cloud Storage | Azure Activity Logs/Blob Storage |
Beginner Mistakes
- Treating every field as requiring strong consistency.
- Using async events for a flow that must be correct before success.
- Publishing an event before the database transaction commits.
- Retrying writes without idempotency.
- Using a cache or search index as the source of truth.
Guided Practice
Practice task
For a ticket booking system, identify three pieces of data that need strong correctness and two that can be eventually consistent.
Sample Answer
| Data | Consistency decision |
|---|---|
| Seat reservation | Strong correctness to prevent two users booking the same seat. |
| Payment status | Strong correctness because money and booking trust are involved. |
| Ticket issuance | Strong enough to issue only once after payment succeeds. |
| Recommendation widgets | Eventually consistent because suggestions can lag. |
| Analytics dashboard | Eventually consistent because reporting can refresh later. |
Module 3 Wrap-Up
You now have the foundation for storage design: model data from product flows, choose storage based on access patterns, design indexes for reads, and protect correctness with transactions and consistency choices.
Before You Continue
- You should know which data is source of truth.
- You should be able to choose SQL or NoSQL with reasoning.
- You should map query patterns to indexes and read models.
- You should know when strong consistency matters and when eventual consistency is acceptable.
- You are ready for Module 4, where data and APIs meet scaling patterns.