Processes in Erlang systems can act as gateways to databases, handle protocol stacks, or manage the logging of trace messages. Although these processes may handle different requests, there will be similarities in how these requests are handled. We call these similarities design patterns. In this chapter, we are going to cover the most common patterns you will come across when working with Erlang processes.
The client/server model is commonly used for processes responsible for a resource such as a list of rooms, and services that can be applied on these resources, such as booking a room or viewing its availability. Requests to this server will allow clients (usually implemented as Erlang processes) to access these resources and services.
Another very common pattern deals with finite state machines, also referred to
as FSMs. Imagine a process handling events in an instant messaging (IM)
session. This process, or finite state machine as we should call it, will be
in one of three states. It could be in an
offline state, where the
session with the remote IM server is being established. It could be in
online state, enabling the
user to send and receive messages and status updates. And finally, if the
user wants to remain online but not receive any messages or status updates,
it could be in a
busy state. State changes
are triggered through process messages we call events. An IM server informing the FSM that the user is logged on successfully would cause ...