I’m trying to plan my application structure and was wondering if someone who knows a bit more about how elixir works under the hood could give me advice on which of my two ideas are more scalable for the least amount of complexity. I am a beginner with Elixir and Phoenix and have really been enjoying it and want to learn more. I want to jump into a full project with it that I have been planning for a while
One thing I have learned about web sockets in other languages is that they have to be scaled in a different way that a simple crud api, so it might make sense to separate them into different services.
There’s three capabilities my backend needs to run. CRUD/HTTP Rest api, scheduled background task (fetching from external data source and writing to db multiple times an hour for about 15 hours every single day), and a real-time chat.
In the future, my application will need to fetch and serve live stream video that runs all the time during the day but won’t run at night.
With other tooling it would make sense to separate these into different services for scaling purposes. Do tools like Oban background jobs and Phoenix Channels solve this scaling issue under the hood? Or would a micro services design still provide scaling benefits?
Most example projects I see are mono repos. I am leaning toward this as it will make modeling relations across services much easier to manage. I’m more just interested in learning how things like Supervisor work. Is what the problem I described the use case for Supervisor / the actor model, or am I totally off base here?
Would love if anyone could point me to some resources on more advanced Phoenix/Elixir topics.
2 Likes
Hi @chris-menz welcome! This is a potentially very large topic, but let me kick it off by providing some answers that I think reflect community norms, lay out the assumptions underlying those norms, and then you can see what may be different in your case.
Simple answers: A single Elixir application that has Phoenix for UI / chat / REST API, Oban for background jobs and postgres as your database would be the recommend place to start.
So, you haven’t actually talked about any scale, so it’s hard to say. But what can be said is that efficient use of Postgres, fronted by Phoenix, will easiliy scale to tends or even hundreds of thousands of concurrent users on a single server.
I would make a choice about separate services depending more on your team and the size of the team than the technologies. If you have just 1 small team, starting with separate services is likely to introduce a lot of complexity, because the boundaries between those services is unlikely to be very clear at the start, and the cost of refactoring is much higher. Deployment becomes significantly more complicated as well.
The way you are framing this is good. Building this to be the scale of youtube at the start is going to be super complex, and you can cross that bridge when you come to it. At the start simplicity is very important so that you can iterate quickly, and you just want to make sure the scaling will be good enough that it won’t cause issues prematurely. A traditional Phoenix app is pretty well tuned to give you what you want here.
To provide anything more concrete though you’d need to be more concrete about what you expect the application to need to do.
6 Likes
Hi @benwilson512 I appreciate the insight and you taking the time to respond. This project is more in the planning phase. The idea is there, but there are several things I need to figure out that are unrelated to software to be able to implement features that will get users.
In an ideal world where I can accomplish that, here’s the demands my application would need to handle. The application is in a fairly small niche, it is regional (New England) and targets surfers, which is gaining popularity but still not a massive community as you can imagine. I also have ideas about an implementation for skiing that would open up many more potential users. So I wouldn’t expect to ever have a crazy amount of users even if the app is super successful. I would consider getting 100+ users a success, but want to build a system that could handle 5000. But like you said, simplicity is also important to me.
The nature of the traffic is spiked too, not linear. Surfing in New England means 2-3 days of good waves followed by long stretches of few waves at all. So the app would need to be able to scale up for a few days to handle increased traffic, and then scale down during periods of low activity. I am planning to deploy this project using Docker and a container orchestration service in the cloud like ECS, using a single region model.
Theres a few types of traffic that these users will generate. I mentioned it a bit in my original post, but essentially there are multiple live video feeds in the application that the user can watch that run throughout the day. So I need live streaming and video optimization. Theres also a live chat feature that I want realtime. Theres also basic data fetching and crud operations. I am knew to building a product of this scale, so I’m not sure if I can give a reasonable estimate on the requests per user.
From what I’ve learned so far, it seems that a Phoenix mono-repo can accomplish all this, leveraging Channels for chat and something like the membrane framework for video (still need to look more into that). I just want to be sure I’m picking the right tool for the job here, as a newcomer to this space.
1 Like
For a newcomer, I think you have a very solid grasp of how to get going. From a raw users standpoint I don’t think you’ll run into any streaming issues at all. Keep in mind the whole elixir package management system ran for a very long time on a single 512mb server. Your ECS + Docker idea sounds like a fine idea, but you could probably get away with simpler depending on whether ECS is something you are familiar with or not.
Live streaming and video work however is an area I know less about, so perhaps someone else can weigh in on that. I’m going to add a membrane tag to the post to see if we can help.
From a code management / maintenance standpoint I definitely think you have the right idea with a phoenix mono repo.
7 Likes
Then you can follow Phoenix’s tutorials and you’re already covered. A brand new app with zero optimizations and no caching will handle even 10k concurrent users just fine.
Though depending on database usage I’d tune some of your Ecto.Repo parameters e.g. queue_target can be a higher value (say 5000ms) so nobody gets the “request timed out” page even in loaded conditions.
And that still wouldn’t be on Elixir, it’d be your DB being the bottleneck.
3 Likes
@dimitarvp @benwilson512 Thank you guys for the feedback. Very much appreciated.
I guess a more general question I have with Phoenix is if leveraging things like channels and implementing features such as video streaming and optimization affects how many users my app can handle.
But it sounds like even with those features I should have no problem scaling.
A lot of it depends on what those channels do, but in The Road to 2 Million Websocket Connections in Phoenix - Phoenix Blog they fit 400k simultaneous channel connections on a single 16gb server.
2 Likes
