# Elixir distributed processing - IoT **URL:** \ **Category:** Questions\ **Tags:** distribution\ **Created:** [September 17, 2019, 10:44am UTC](https://forum.elixirforum.com/t/elixir-distributed-processing-iot/25454 "2019-09-17T10:44:12Z")\ **Posts on this page:** 1\ **Showing post:** 7
**Author:** ![elcritch](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/elcritch/32/15758_2.png) [@elcritch](https://forum.elixirforum.com/u/elcritch)\ **Post date:** [September 20, 2019, 2:45am UTC](https://forum.elixirforum.com/t/elixir-distributed-processing-iot/25454/7 "2019-09-20T02:45:47Z")
PS Another option that might fit your needs really well would be to checkout if Phoenix Presence ([Using Phoenix Presence | What did I learn](https://whatdidilearn.info/2018/03/11/using-phoenix-presence.html)) could work for you. Presuming it handles node draining and syncing, but it handles duplicate messages and synchronizing presence data which seems very similar to your case. Ie one chat room per device or similar and it scales really well and is “first class” in Elixir/Phoenix world. > [@lucaong](#): > > Would it make sense instead to keep this car state in some store, like Redis, or some other data store fast enough for your use-case? If they went that route, it’d make more sense to use ETS or Mnesia as they’re native to Erlang and could run in the same cluster. Redis would require another stack… But mnesia has some nice features that’d work well for this kind of case. With mnesia it seems you could remove the one process per trip model. P.S. @tomazbracic you might talk to someone like Erlang Solutions who could help put you on a good architecture path of you want to go 500x quickly. 🙂 --- _[View the full topic](https://forum.elixirforum.com/t/elixir-distributed-processing-iot/25454)._