4 ms·
Sure, but I think the point is that it's unlikely the bottleneck will be in the web server, but in whatever database you're using for your logins. Just because
by aflag 5y ago
Sure, but I think the point is that it's unlikely the bottleneck will be in the web server, but in whatever database you're using for your logins. Just because you have a single program, it doesn't mean it is required to use a single database.
But even if the webserver is the problem, it feels unlikely that you'll end up saving much in infrastructure cost by scaling just the login service rather than just deploying more copies of your webserver.
Not saying it is impossible, but it's unlikely for that to be a good justification to adopt microservices. I'm not saying that there aren't good reasons to use microservices, but I agree that scalability is not a good selling point. I'd actually argue that it's harder to build scalable microservices than monoliths.
- JamesSwift 5y agoIm not arguing for or against (I'm pretty against micro services), I'm just explaining what the arguments are
- darkwater 5y ago> Just because you have a single program, it doesn't mean it is required to use a single database. I would challenge that. Obviously a well written "monolith" with well insulated modules, separation of concerns etc can use different databases but I heard too many times when I ask "why can't we shard the database" the answer "the data model is one and it's way easier to develop on one single data model that on N models inside the monolith".