ACID Properties in SQL

Ensuring Complete and Reliable Transactions

BY:-SUJAL RATHORE
GROUP:-I
The ACID properties are a set of principles that ensure
reliable processing of database transactions. They stand for:
 Atomicity in SQL
UNDERSTANDING ATOMICITY

• Atomicity ensures that all parts of a transaction are completed

successfully or none at all.
• If a transaction fails, changes are rolled back.
• Example: Bank transaction (deducting and adding funds must
both succeed or fail).
 REAL LIFE EXAMPLE OF ATOMICITY
1.Failed Transaction:

1. Scenario: Two friends, Alice and Bob, decide to send money to each
other. Alice sends money to Bob online, but due to an issue (e.g., a
server problem), the transaction fails. Alice’s account is debited, but
Bob's account is not credited.
2. Key Points:
1. Alice’s account is deducted the money.
2. Bob's account shows no change.
3. Both friends are puzzled, worried about the missing money.

2.Atomicity Resolves the Issue:

1. Scenario: Due to atomicity (transaction integrity), the system
automatically reverses the failed transaction, returning the money back
to Alice’s account. Both Alice and Bob are happy when they notice the
refund and the transaction gets completed successfully.
2. Key Points:
1. Money is refunded back to Alice.
2. Both friends are happy and celebrating.
3. Atomicity ensures that the transaction is either fully completed or
fully rolled back.
Scenario: Online Shopping Payment Transaction

Imagine you are buying a product from an online store. The transaction
involves two key operations:

1.Deducting the money from your bank account.

2.Updating the order status in the store's database to confirm that the
product has been purchased.

Atomicity ensures that both of these operations are completed

successfully or, if something goes wrong, neither operation is applied. This
ensures that if any part of the transaction fails, the system will not deduct
money without updating the order status or vice versa.

Steps in the Transaction:

1.You initiate a payment of $100 for an item.
2.The system first deducts $100 from your bank account.
3.Then, the system updates the order status to "paid."
4.If either of these steps fails (e.g., due to a network issue or payment
gateway failure), both operations are rolled back.
 1. Rollback: The money is refunded to your bank account, and
the order status is not updated.
Key Point:
•Atomicity ensures that the transaction is all or nothing. If there’s a
failure after the first step (money deducted) but before the second
step (order updated), the system will cancel the entire transaction
and reverse the deduction.
 ADVANTAGES OF ATOMICITY

• - Maintains data integrity.

• - Prevents partial updates.
• - Ensures all-or-nothing execution.

• Example: Avoids issues like deducting money without

updating balances correctly.
 DISADVANTAGES OF ATOMICITY

1.Overhead in Transaction Management: Ensuring atomicity adds extra

processing overhead due to maintaining transaction logs and rollbacks.
1. Solution: Optimize transaction management systems, implement efficient
logging mechanisms.

2.Reduced Performance in Large Transactions: Atomicity can slow down

performance, especially when transactions involve large amounts of data.
1. Solution: Break large transactions into smaller ones or use distributed
databases.

3.Limited Flexibility: Atomic operations may lack flexibility in handling

exceptions or partial updates.
1. Solution: Implement compensating transactions for handling partial
operations.

4.Complex Error Handling: Ensuring rollback in case of failures can be

complex in systems with interdependent transactions.
1. Solution: Use advanced error recovery techniques and tools for better fault
tolerance.
ATOMICITY DEMONSTRATION:
SQL QUERIES
 ALTERNATIVES TO ATOMICITY

• - Eventual Consistency (NoSQL).

• - Saga Pattern (Microservices).
• - Two-Phase Commit (Distributed Systems).
• - Use cases where strict atomicity can be relaxed.
There isn't a direct alternative to Atomicity in the context of ensuring transaction
integrity in SQL databases, as it is a foundational concept of transactional
databases. However, depending on the use case and the level of data consistency
required, there are alternative approaches or strategies that can offer similar
guarantees or manage transactions differently:

1. Eventual Consistency (Used in NoSQL Databases)

•Description: In distributed systems or NoSQL databases like Cassandra or
DynamoDB, eventual consistency allows updates to propagate gradually. The
system eventually becomes consistent after some time, but it doesn't guarantee
immediate consistency as ACID transactions do.
•Trade-Off: Sacrifices immediate consistency for higher availability and partition
tolerance (as per the CAP theorem).
•Use Case: Suitable for systems that can tolerate temporary inconsistencies, like
social media updates or user-generated content platforms.

2. Saga Pattern
•Description: A long-lived transaction is split into a series of smaller, isolated
steps, each with its own compensating transaction to undo the work if something
goes wrong. This is common in microservices architectures.
•Trade-Off: Complexity increases because developers must explicitly define
compensation logic for each step.
•Use Case: Useful in scenarios like order processing systems where various
services (inventory, payment, shipping) must be coordinated.
3. Two-Phase Commit (2PC)
•Description: A distributed transaction protocol ensuring that a transaction either commits
across all involved databases or rolls back if any one part fails.
•Trade-Off: It can be slower and more resource-intensive, especially in distributed systems,
due to the need for coordination between multiple nodes.
•Use Case: Ideal for systems requiring strict consistency across distributed databases.

4. BASE Model (Basically Available, Soft state, Eventual consistency)

•Description: Unlike ACID, BASE provides a more flexible approach that is more lenient with
consistency to achieve higher availability and scalability.
•Trade-Off: Immediate consistency is not guaranteed; instead, it provides eventual
consistency.
•Use Case: Suitable for systems like shopping cart services or user session storage, where
immediate consistency is less critical.

5. Idempotency
•Description: Ensuring operations can be applied multiple times without changing the result
beyond the initial application. This can be used to achieve consistency in scenarios where
atomic transactions are not possible.
•Trade-Off: It requires careful design to ensure that operations are idempotent.
•Use Case: Common in distributed systems for operations like payment processing or API
calls, where retries can occur.
Each of these alternatives provides different trade-offs between consistency, availability, and
partition tolerance, tailored to the specific needs of different systems or applications.
 OPTIMIZING ATOMICITY

• - Faster logging methods (WAL).

• - Grouping operations.
• - Database tuning.
• - Asynchronous commits.
• - Idempotent operations.
•Faster Logging Methods (WAL):

•WAL stands for Write-Ahead Logging.

•Ensures data integrity by logging changes before committing them.
•Speeds up recovery after crashes.

•Grouping Operations:
•Batches multiple operations into a single transaction.
•Reduces overhead and improves performance.

•Database Tuning:
•Optimizes database performance through adjustments.
•Includes indexing, query optimization, and hardware tuning.

•Asynchronous Commits:
•Commits changes without waiting for the physical write to disk.
•Enhances performance by reducing commit time.

•Idempotent Operations:
•Operations that produce the same result even if executed multiple times.
•Useful in scenarios to ensure consistent outcomes, particularly in retries.
 REAL-LIFE USE CASES

• - Banking systems (transactions).

• - E-commerce (order processing).
• - Reservation systems (seat bookings).
 CONCLUSION

• Atomicity ensures reliability in database transactions.

• Critical for systems requiring high data integrity.
• Can be optimized to reduce overhead.
CONSISTENCY IN SQL
 UNDERSTANDING CONSISTENCY

• Consistency ensures that any transaction will bring the

database from one valid state to another.
• All data rules, constraints, and relationships are maintained.
• Example: Enforcing foreign key constraints in a relational
database.
 REAL LIFE EXAMPLE OF CONSISTENCY
Scenario:

When a customer books a flight ticket, the system must ensure that:
1.The seat is available.
2.The booking is successfully completed, updating the seat's status as booked.
3.The customer's payment is processed.
Consistency Ensures:
•The seat inventory is correctly updated.
•No two customers can book the same seat simultaneously.
•The booking and payment processes are synchronized.

Process:
1.Before Booking:
1. Available seats for Flight XY123: Seat 1A, Seat 1B, Seat 1C.
2. Customer chooses Seat 1A.

2.During Booking:
1. Check if Seat 1A is available.
2. Reserve Seat 1A.
3. Process the payment.
4. Confirm the booking and update the seat status in the database.
• After Booking:

• Seat 1A is marked as booked.

• The customer's transaction is recorded.
• No other customer can book Seat 1A.
• If an error occurs (e.g., payment fails), the system must roll back
the seat reservation to ensure consistency. This way, the seat
remains available for other customers, and no incorrect
bookings occur.
Scenario:
In an online shopping platform, when a customer places an order, the system must
ensure:
1.The items are in stock.
2.The order is confirmed only after the stock quantity is updated.
3.The payment is processed successfully.
Consistency Ensures:
•The stock levels are updated accurately.
•The order is only confirmed if the items are available and payment is successful.
•No two customers can order the last item at the same time.
Process:
1.Before Order:
1. Product X has 10 units in stock.
2. Customer places an order for 2 units of Product X.
2.During Order:
1. Check stock: 10 units are available.
2. Reserve 2 units.
3. Process the payment.
• After Order:
• Update stock: 8 units remain.
• Confirm the order and notify the customer.
• If an error occurs (e.g., payment failure), the system must roll back
the stock reservation, ensuring the product quantity remains
consistent and available for other customers.
 ADVANTAGES OF
CONSISTENCY
- Maintains the correctness of the database.
- Ensures data validity and integrity.
- Prevents illegal transactions.

Example: Prevents entering an invalid order without a corresponding

product.
Disadvantages of Consistency
• Slower Performance:
• Issue: Checking rules can slow down transactions.
• Solution: Improve database design, queries, and use caching.

•Hard to Manage in Distributed Systems:

•Issue: Keeping data consistent across many servers is tough.
•Solution: Use systems designed for consistency or special algorithms.

•Limits Growth:
•Issue: Strict rules can make it harder to handle more users.
•Solution: Use different consistency levels where possible, like eventual consistency.

•Conflicts with Large Operations:

•Issue: Problems can occur during large data changes.
•Solution: Delay checks or check data in the application before saving.

•Too Strict for Some Apps:

•Issue: Not all apps need strict rules, like social media feeds.
•Solution: Use less strict rules for parts of the system that don't need them.
 ALTERNATES FOR CONSISTENCY
1.Eventual Consistency:
1. Data will become consistent over time, but not immediately.
2. Used in distributed systems where high availability and partition tolerance
are more critical.

2.BASE Model:
1. Stands for Basically Available, Soft state, Eventual consistency.
2. Focuses on availability and performance over immediate consistency.
3. Common in NoSQL databases like Cassandra and DynamoDB.

3.Causal Consistency:
1. Ensures related changes are seen in the correct order.
2. Useful in collaborative applications where the order of operations matters.

4.Read-Your-Writes Consistency:
1. Guarantees that once a write is completed, subsequent reads by the same
client will reflect that write.
2. Useful for user-specific data, like a shopping cart or profile updates.
These alternatives provide more flexibility and better performance in scenarios
where immediate consistency is not a strict requirement. Would you like to dive
deeper into any of these?
 Use Cases of Consistency:

1.Online shopping: Stock updates during order placement.

2.Banking: Account balance updates during transfers.
3.Flight booking: Preventing double seat bookings.
4.Hotel booking: Real-time room availability updates.
5.Food delivery: Updating menu items and stock.
 Conclusion for Consistency:

Consistency ensures accurate, reliable, and synchronized operations

across systems. It prevents conflicts, ensures data integrity, and enhances
user trust by maintaining seamless experiences in real-time, even during
failures. Consistency is critical for smooth operations in domains like e-
commerce, banking, booking systems, and more, ensuring data
correctness and system reliability.
QUESTIONS AND ANSWERS