Seven Key lessons for Concurrent

In the future, we expect to see a return of distributed programming with increasingly fine-grained distributed systems that will make systems look more and more like classic concurrent systems. We have learnt a lot about building concurrent systems, and he accentuates seven key lessons:

• Think about communication first. It needs to be part of the architecture of any distributed application. Ad-hoc communication leads to reliability woes. Actors and queues are examples of good patterns.
• Schema helps, but don't blindly trust it. The server always changes at a different rate than clients, and Duffy points to Internet as a good reference that works very well.
• Safety is important, but elusive. Lack of safety creates hazards through races, deadlocks or undefined behaviours. The preferred form of safety is for Duffy to be isolated. If that's not possible you should be immutable. If that's not possible either, you have to resort to standard synchronization mechanisms.
• Design for failures, because things will fail. Duffy thinks we should design for replication and restartability and notes that error recovery is a requirement for a reliable concurrent system.
• From causality follows structure. The cascade of events that leads to an action being taken can be very complex in a concurrent system. A context that flows along can simplify keeping track of all that happens.
• Encode structure using concurrency patterns to make it easier to understand a system. Two of Duffy's favourite patterns are Fork-Join and Pipeline.
• Say less, declare/react more. Declarative and reactive patterns are great for delegating hard problems to compilers and frameworks. He sees Serverless as a specialization of this idea with a single event and a single action.