<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><blockquote type="cite"><div>If i try to compare what i learn in <a href="https://learnyousomeerlang.com/distributed-otp-applications">https://learnyousomeerlang.com/distributed-otp-applications</a> with my experiences, i can't see the benefits of distributed erlang/otp app that explained in the book. <br></div></blockquote><div><br></div><div>And you are probably right.<br></div><div><br></div><div>There is an important note in that chapter:<br></div><div><br></div><blockquote type="cite"><div><b>Note:</b> In terms of distributed programming fallacies,
distributed OTP applications assume that when there is a failure, it is
likely due to a hardware failure, and not a netsplit. If you deem
netsplits more likely than hardware failures, then you have to be aware
of the possibility that the application is running both as a backup and
main one, and that funny things could happen when the network issue is
resolved. Maybe distributed OTP applications aren't the right mechanism
for you in these cases.<br></div></blockquote><div><br></div><div>If you have a service that, for whatever reason (like not being a stateless service), you only can have 1 instance active at a time but you have additional nodes you can use as backups in case of hardware failure on the current active node then distributed applications are an answer.<br></div><div><br></div><div>Tristan<br></div></body></html>