und0ck3d

und0ck3d

Hey! Hope everyone is doing fine during these times!

I know lots have been discussed here regarding doing microservices architecture in Elixir/Erlang but I still have some questions regarding a particular way of doing it using processes shared between nodes in a cluster of Erlang nodes. I was kind of inspired to try this out by this article from @josevalim Elixir in times of microservices « Plataformatec Blog.

I’ve created a repository (https://github.com/crqra/ms_ex_arch) with some demo apps to demonstrate an architecture based on the Erlang remote processes’ features. It includes two services: order_service and user_service; and a web api for frontends to interface with the services. Find instructions to run the demo in the repo’s README file.

Each service has a GenServer with which all other services and (Elixir) apps can interact with and they’re started with a name that should be known to other services who want to interact with it and registered globally.

For me, as my experience with the “distributed” features of Erlang isn’t that much, this architecture seems like a very good approach to “microservices”. However I’m pretty sure I’m missing the hidden/not so clear issues that such architecture would create and that’s why I’m writing you this, to get your help with those.

For example, globally registered processes is a nice way to easily know the correct process we’re interested between nodes, but I’m aware that each name must be unique so it’d create an issue if we would like to scale for instance the order_service. From my readings I believe this could be fixed using :pg or swarm for grouping processes but how would for instance the web app know which process to call based on the node that is having the last pressure? Would this be an issue at all if back-pressure would be correctly implemented or pools used in the first place on the single order_service?

Other question would be: given that when an Erlang node (A) connects to another (B) that’s already connected to (Z), (A) would automatically be connected to (Z) as well even though it just wanted to talk to (B) in the first place. This seems fine if we only have 10s of services; but how does this behaves if we have 100s or 1000s of services in our architecture? Can someone point out resources for further research, please?

And last question would be how this nodes would be able to communicate if they’d be running in different networks? This isn’t so much related to the overall topic, but my lack of experience requires me to ask. How could I’ve the nodes communicating for example if web would be on a public network but order_service and user_service would be on a private (internal) network? Would there be issues?

Sorry for the somewhat confusing topic, feel free to suggest changes to this initial message or point me out to resources I’ve might not have found based on my questions.

Thanks in advance for any help!

Kind regards,
João

Showing Posts 1 to 2

al2o3cr

al2o3cr

One big issue: each “service” in this setup is single-threaded. Calls back into the same service will deadlock and crash. For instance:

  • application code calls OrderService.list_orders

  • OrderService.list_orders calls UserService.get_user

  • if UserService.get_user tries to interact with OrderService, it will crash because OrderService is already waiting for a reply from UserService

Connections between nodes are usually static and made at boot-time. They aren’t quite the same thing as opening an HTTP connection to another server for one request.

A good place to start reading about building things with processes in the BEAM is the oft-cited “To spawn, or not to spawn?”

mbuhot

mbuhot

Designing for Scalability with Erlang/OTP has a chapter on distributed architectures that you might find useful.

— All posts loaded —

Where Next? Top

Trending in Discussions Top

AstonJ
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
2977 94592 917
New
cblavier
Hey there, It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
heathen
Quite interesting article Google brought me. Didn’t find any mentions about it here. What do you think in general? Would you use togethe...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
axelson
Hi there! :wave: @frigidcode and I (but mostly him) have been running an Elixir Book club, we’re almost done with Designing Elixir Syste...
New
budgie
A little off-topic, but I feel like people here have a good head on their shoulders. I used to be quite good at making software. Was luc...
New

Other Trending Topics Top

GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
georgeguimaraes
Just published claude-code-elixir, a plugin marketplace for Claude Code with Elixir support. These are the plugins I’ve been using for my...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews