#Can you help me out on a system design?

1 messages · Page 1 of 1 (latest)

winter burrow
#

I wanna build a scalable chat enabled project that can run both in Mobile and web ...we decided to use elixir for backend and react for frontend

The thing is I was been suggested to design a microservices architecture.. maybe since I'm new to elixir i can't find many resources to understand best practices i can follow or decide whether to use it or not

If i did what api gateway would elixir supports the most ?

Or

Doing a big monolithic app gonna suffice?

You know it's pretty confusing i appreciate your suggestion and your experiences on using elixir for backend which may relate to my issue

fossil mantle
#

It's a little hard to give really detailed advice based on a few sentences.

My personal suggestion would be to not use microservices until you really feel the need for it and understand how it might help you. Just because some project is monolithic doesn't have to make it big. An API gateway should be language agnostic as it uses predefined protocols (HTTP/WebSockets, JSON/XML/ProtoBuff).

My suggestion would be to start small, make an estimate of how much traffic etc you're expecting and when you have a small prototype test it according to your assumptions. If it works continue building, if not look for improvements (which maybe maybe maybe might be microservices)

winter burrow
fossil mantle
#

What is really huge, Facebook size ? Are we talking about 10K simultaneous users or 3 million ? The BEAM is capable of handling largish numbers, Discord also runs on Elixir 😉

If you get a really huge number of audience it's very important to be able to have good observability so if something doesn't go as planned you're able to adjust. That's why I stress that I think it's more useful to build a prototype, test it well, make sure you're able to locate bottlenecks etc and go from there.

#

One extra thing to note: an Elixir (/OTP) project is already split up into smaller Applications which work together through message passing, so it's kinda like having (nano) services in a project. If you really feel the need to split things up, you could start there and split it up into different projects/micro services later on.

#

I hope it helps a bit, feel free to post additional questions if it doesn't make sense

kind walrus
#

It's worth noting that discord didn't start with a microservices architecture, nor does a microservices architecture necessarily improve scalability. Understanding bottlenecks and single points of failure is what allows you to scale.

#

It's also incredibly unlikely that you'll need to scale all at once, and as tuxified said, the BEAM VM is great at handling large numbers of things.

#

...a well implemented system can likely support hundreds of thousands of users per physical server

modern topaz
#

micro services is a solution to an organizational problem of “my engineers are tripping over each other” If you don’t have enough engineers to have that problem, you probably won’t benefit from microservices

#

(I have a team of eight that maintains like 15 “micro” services and the ops work alone is a ton of work before you even get to the real product work)