Microservice the OTP Way - Diede Claessens | Code BEAM Europe 2025

[music] [music] [applause] Yeah. Yeah, they are a hot topic. They are. So, I'm Da. I'm a senior software developer at Starfish. Here are some stuff I had to put on the slides. So, Starfish is the creator of Hellgate. Uh we solve tricky problems in the payment and banking world. Um our products are built for uh composibility and we are an efficient but still a small team uh that has an impact. If you want to learn more about Hellgate, you can scan that link and um arrive on a web page I guess. [laughter] Um so microservices are cool for a long time especially in the nonbeam ecosystems and I can imagine on all the architecture meetings you had these conversations about microservices it solves every problem like you had the questions about scalability let's use microservices you had questions about team autonomy Microservices. Maybe you felt bored. Microservices. So when we started building Hellgate, our product, we were like, "Hell yeah, let's do microservices. The big guys do it. Why we cannot do it?" And so microservices, they are cool until they are yours. Um 2 years after we made this [snorts] decision um we had all this Kubernetes Kafka matches BS all of this like microser bingo terms you can imagine um but it's a lot of context you need to keep in mind when you're developing when you're building it. It's just at at some point it's hard to understand everything. Um so maybe first we go back to basics what were microser what are they trying to solve um and with my extensive research i.e. asking ZPT, I came to like four reasons like one of them were they reduce complexity and this one made me think a bit how how does it reduce complexity? It reduces complexity of the service. So you build a smaller service so the complexity of that service is less than the complexity of a big service a monolith which makes sense. Um scalability they want to scale things differently. Uh something is has bigger load they want to scale it separately. Uh fault isolation is one of them and independent team ownerships and actually they are valid valid goals I can imagine but the downside is they only work well if you are 200 plus engineering team. Um a bit of a caveat for this. It's not because you are 200 engineering team. This means that you need microservices like the beam. If you just would use the beam, just imagine what 200 engineering people can do with just the beam. And we are not a big team. So some fancy transition. We learned it the hard way. Um so we started building microser you had some cotlin some swift we were typing on our machines producing boiler plate all day um if you don't see the like the resemblance that's me um but in the end we had a product that worked and as a team we were proud of what we achieved but local development local testing was becoming a bit of a nightmare. Um, then we learned some elix some Erlang and Elixir and we saw what OTP and beam has to offer. You basically get concurrency isolation and full tolerances. You get them built in, not bolted on. Um, and this for me personally open my my was crazy what what it could do was crazy. Um the [snorts] beam and OTP they give you superpowers so we should use them. It's basically a micros service platform without an ops burden. You can do microservices without um network overhead. Um [snorts] yeah, [sighs] if if you say it like this microser platform, you still need to write good code. Um it's not because you writing a monolith that you can just type create modules whenever you want. Um you need to still break things apart. you still need to compose in a functional way modules and functions together. >> [snorts] >> Um so we really try to focus on building um focused processes and modules. Um and then if you do if you build a good module you instead of having a separate deployment here just have a good module and you don't have any firewalls that are in front of them that makes things more difficult. If you just just separate everything in good modules, yeah, life is good. Life is really good in uh monolith land, let's say. Um these separation of good modules and clean codes, it's not a term I really want to use, but I said it so I cannot take it back. [laughter] Um if you write those good modules, life is good. You're as a team you become fast, you are productive. Um it's a joy to work in. So my one of the key takeaways I want to give you is write good modules instead of microservices. And if you're still in an architecture meeting and you need a good name to convince your colleagues, let's create one. Let's call them modulates. So now you can convince your people that you you're smart. You you gave something cool name. No, now you can do this. And basically this like modules and monoliths concatenated together. Um but there is still some downsides like with the great power that OTP and the beam gives you. There's like one downside we really felt. Um, and that's soft boundaries. There's nothing stopping you from sending a message to a process of calling a module like five layers deep in your code. You have to be disciplined. Um, I like to say O2 doesn't stop you from shooting yourself in the wood in the foot. It just restarts the process afterwards. Um and a second reason um that we came across was um compliance was a bit of a headache for our team because we were so small. If you do some compliance stuff, um your code base gets under scope. And although OTP and beam gave us a lot of superpowers, um because we were Superman, uh we met a villain and this villain is PCIDSS. Um basically we had to handle raw card data. So raw credit card data and when you handle this [snorts] the modules that handle this if it's inside a codebase the whole codebase is inside scope. Um for me personally as a developer the main thing that bothers me was uh PRs like reviewing PRs would take just longer because higher management had to look uh at the code that it was still uh compliant because um I think it's a phrase in the PCI the one operating the code cannot be the one who uh builds the code or if you want just read the specifications they say it better than me. Um [snorts] but we had an idea if this module that handles this is so difficult why don't we split it why don't we create a separate service that does this so a micros [snorts] service um and actually that [snorts] helped us because we did the good modules we already had it split we defined clear boundaries. We uh had a API so we could split. We just had to put some Phoenix in front of it. Um but again this was not the only thing we came up with. Um so [snorts] you have these good modules and sometimes your modules are so good that they become products. So suddenly you created a product and we had some products um we had some modules that did like uh car tokenization um orchestrating payments and they were so good that clients came to us and we said we don't actually need all of it we just need that. So we took the modules and we created services or otherwise you can always promote a module to a service when it's ready to leave home or you can give it the kit analog analogy when you uh are lucky enough to become a parent you don't put your child on the streets on day one you wait until they are grown up and ready to live on their own And this is also something I want to like add. I didn't create a slip for there, but it's a note I want to add is like good architecture um grows with your team, not ahead of it. So don't start with microservices. Start in a monolith in a module. Um create good modules and when they're ready to leave home, let them. It's not not something we shouldn't do. It's something we shouldn't do in the first place before um just because you know uh so yeah thank you for listening. [applause] [applause] >> I have no idea how I did on time. >> No, you did really good. We have some time for for quick questions here. I really had to think of Eric's talk earlier. So we heard like in financial uh institutions uh boundaries are important and soft boundaries. So that that's really great. It seems like there's some some common [snorts] waves here. >> Yeah. >> The first question, >> how much was the meeting overhead reduced? >> Oh, was now we have one meeting a day still. So we need to get rid of that. But yeah, like a lot of less like less headache. just less headache. You don't have all these like overheads. You don't have a ops team that needs to know everything you do like oh yeah we we want to do some message spect message passing we need this MQ broker or we need this database for this service because we felt like doing bongo instead of Postgress. Um so yeah it's yeah it's it's better. Yeah >> thank you. >> Do we have a hand there? Yeah. [snorts] >> How are you enforcing these uh soft boundaries? Is it at the level of a code review or is it at the level of automated tooling like boundary? >> Yeah, it boundary is a good uh this was something I was debating on adding which is a good library. We didn't use it. We did it pure on discipline [laughter] and like code reviews and but still it sometimes bites you in the foot. Um, sometimes you're less careful, you're pressured by deadlines and you make a mistake, which can happen. Um, which is also a a again a thing to say about why we splitted the compliance part away because if we needed to make changes, we were faster to do it in the rest of the codebase that didn't need to be compliant. So, we could make changes faster if we were not disciplined and made some mistakes. So uh yeah but boundaries are good. We also tried umbrellas but that was a whole other issue on its own. So yeah [laughter] felt that >> thank you so much da [applause] [music] [music]

✨ This talk was recorded at Code BEAM Europe in November 2025. If you're curious about our upcoming event, check https://codebebeameurope.com ✨ --- Microservices remain a hot topic, but their complexity and operational overhead often outweigh the benefits. OTP provides a powerful foundation for building distributed systems, yet much of this power is lost when trying to implement traditional microservice architectures. In this talk, we’ll explore how to use OTP to build microservices that are scalable, resilient, maintainable, and composable. We’ll discuss how to decompose a monolith into microservices - and even how to reverse that process - based on evolving client and business requirements. We’ll demonstrate how OTP enables truly composable microservices, share when it makes sense to “OTP” and when it doesn’t, and look at the common pitfalls of traditional microservices we’ve learned to avoid. --- Let's keep in touch! Follow us on: 💥 Bluesky: / codebeam.bsky.social 💥 Twitter: / codebeamio 💥 LinkedIn: / code-sync