4 ms·

Can you explain more?

liveoneggs 7y ago
probably just using ETS out of the box
the_duke 7y ago
Erlang/OTP provides a system of stateful processes that communicate via message passing, with a focus on resiliency and fault tolerance. These processes can seamlessly interoperate while running on multiple machines. This makes building stateful application servers a pretty natural fit.
wmeddie 7y ago
Systems like Erlang/OTP, Akka, Orbit and Orleans/Service Fabric are built on an actor model where domain objects of the system (e.g. Users, Accounts, Invoices, etc.) exist within the cluster and have a an address so they are like having a bunch of mini servers. These servers typically keep their state in memory so they can respond to query messages quickly. Plus the application can unload idle (or no longer necessary) actors and restore their state when they are needed again. It's very similar to the Linked in-memory key-value idea mentioned in the paper.
- cuddlecake 7y ago
  I think it is an anti-pattern to design a system where each domain object is a process. Sometimes data is just data and should be managed as such. I think what makes actor models so nice is the explicit ownership of state. It is not possible to declare "var x = 1" in one file, and access x in another file. You always have to retrieve state explicitly, otherwise it won't be accessible within the scope of your function.
sb8244 7y ago
We do this for several key elements of a high throughput service. It keeps the critical path local only. The flow is to dual write to our rdms and a local process. The process either stores in ETS or an process state map. It also broadcasts out the event to the cluster. When a node in the cluster gets a message, it executes on it. Process startup is restored from the DB which is still authority. Generally this is really easy to do in Elixir. Maybe 50 lines of code for the system described (minus DB code), much of it definition lines.

probably just using ETS out of the box

Erlang/OTP provides a system of stateful processes that communicate via message passing, with a focus on resiliency and fault tolerance. These processes can seamlessly interoperate while running on multiple machines. This makes building stateful application servers a pretty natural fit.

wmeddie 7y ago

Systems like Erlang/OTP, Akka, Orbit and Orleans/Service Fabric are built on an actor model where domain objects of the system (e.g. Users, Accounts, Invoices, etc.) exist within the cluster and have a an address so they are like having a bunch of mini servers. These servers typically keep their state in memory so they can respond to query messages quickly. Plus the application can unload idle (or no longer necessary) actors and restore their state when they are needed again. It's very similar to the Linked in-memory key-value idea mentioned in the paper.

cuddlecake 7y ago
I think it is an anti-pattern to design a system where each domain object is a process. Sometimes data is just data and should be managed as such. I think what makes actor models so nice is the explicit ownership of state. It is not possible to declare "var x = 1" in one file, and access x in another file. You always have to retrieve state explicitly, otherwise it won't be accessible within the scope of your function.

sb8244 7y ago

We do this for several key elements of a high throughput service. It keeps the critical path local only. The flow is to dual write to our rdms and a local process. The process either stores in ETS or an process state map. It also broadcasts out the event to the cluster. When a node in the cluster gets a message, it executes on it. Process startup is restored from the DB which is still authority. Generally this is really easy to do in Elixir. Maybe 50 lines of code for the system described (minus DB code), much of it definition lines.