Designing a lock failsafe with arduino. Questions about reliability and design
What do you mean by 'failsafe'?

Do you want fail open, so if there's a fire that damages the electronics, people can still get out alive? 

Do you want fail closed, so that if prospective burglars crash the electronics with a spark lighter, they still can't get in?

You can have both if you opt for a 'nightlatch', which can always be opened from the inside, and have the unlock from the outside fail closed. But then that always opens from the inside.

You cannot have all three, personal safety from inside, and access barring from both sides in the event of a failure.

If you use a motor and gearbox to move a deadbolt, then any high ratio gearbox will be difficult to push back. A worm gear is impossible to push back if the efficiency is &lt;50%, and you have to work really hard to get worm efficiency higher than that.

Going to a nightlatch release, there are two types of lock. Blocking, and transfer. You can make either work with a solenoid, which is locked in the power-off condition. As it doesn't have to actually move the bolt, it could be quite low power so suitable for battery use. 

A blocking mechanism is the easiest to make work, but it's also the least secure. Something that can be withdrawn by the solenoid gets in the way of the link from handle to bolt. This has the disadvantage that if someone uses enough force on the outside handle (and they will feel the block preventing movement) eventually something will break. If the block breaks, they have access. If something else breaks, you still have a busted lock. Early Mini's could be opened by slipping a 12" piece of steel tube over the door lever, and leaning on it.

A transfer mechanism is better. The handle moves freely but impotently when locked, with no link to the bolt. On unlock, the solenoid inserts the final link into the movement chain. This is far better. You can concentrate all the vandal-surviving strength in the simple handle, and as the bad guy can feel it move freely, he is not tempted to apply force.

That's all locks and mechanics. How about the electronics? It needs to check battery state, and bleat if it's low. How do you stop it being crashed by a spark lighter? Watchdogs to bleat and reset, and 'crash-guards', jumps to a 'help I'm being hacked' rescue function, installed throughout your interrupt vector table, and in all unused portions of your code. And no monolithic code, insert jumps over your crash-guards. This raises the likelyhood that if the program counter gets corrupted, you will soon execute a jump to its rescue code. And as MCUs are pretty cheap, triple redundancy?