ACID means you have transactions. And transactions are a fantastic feature. It's like a save point in a video game.
Use case for yesterday:
- create a user and it works, create a default access right for this user for one of our most important service;
- if this doesn't work, cancel everything.
Now I had the creation of user working, but the creation of the access right had some problems unrelated to the code.
Without a transaction, this bugs led to 100 of user accounts created without a default right access, and we had to clean it up after ward.
With a transaction, this bug would have not affected us in any way.
Transaction are safety net for data corruption. When you are using mongo, you have to manually do that logic again, and again and again.
In my experience, most mongo coders don't do it, and their DB is riddle with duplicates, incomplete inserts and such. Transactions give it to you, for free.
There are many other wonderful things about transaction:
- free manual rollback. Even when you don't have an error, reverting an operation is one line of code. Even if it affects many tables. Doing that with mongo or redis is terrible.
- free race condition handling. This one is huge because race condition are very, very hard to deal with. E.G: you want to limit the number of comment per day for untrusted users. You just add the comment, THEN check if you have more comments that acceptable, and if yes, roll it back. This way if your system if flooded with comments, you never have one slipping through.
- free ability to split your process in small units. You can create subtransaction inside transactions, and just say you want to rollback one but accept the other part. This give you huge granularity on your error handling.
Basically you get precise, clean, strong and easy reliability for close to nothing.
As soon has you have many untrusted users using your system, it becomes a fantastic asset.
Use case for yesterday:
- create a user and it works, create a default access right for this user for one of our most important service;
- if this doesn't work, cancel everything.
Now I had the creation of user working, but the creation of the access right had some problems unrelated to the code.
Without a transaction, this bugs led to 100 of user accounts created without a default right access, and we had to clean it up after ward.
With a transaction, this bug would have not affected us in any way.
Transaction are safety net for data corruption. When you are using mongo, you have to manually do that logic again, and again and again.
In my experience, most mongo coders don't do it, and their DB is riddle with duplicates, incomplete inserts and such. Transactions give it to you, for free.
There are many other wonderful things about transaction:
- free manual rollback. Even when you don't have an error, reverting an operation is one line of code. Even if it affects many tables. Doing that with mongo or redis is terrible.
- free race condition handling. This one is huge because race condition are very, very hard to deal with. E.G: you want to limit the number of comment per day for untrusted users. You just add the comment, THEN check if you have more comments that acceptable, and if yes, roll it back. This way if your system if flooded with comments, you never have one slipping through.
- free ability to split your process in small units. You can create subtransaction inside transactions, and just say you want to rollback one but accept the other part. This give you huge granularity on your error handling.
Basically you get precise, clean, strong and easy reliability for close to nothing.
As soon has you have many untrusted users using your system, it becomes a fantastic asset.