# Vassil Popovski on LinkedIn Re: scalability

- **期号**: SRE Weekly Issue #432（2024-07-07）
- **作者**: Vassil Popovski
- **链接**: https://www.linkedin.com/feed/update/urn:li:activity:7209281234160537603/

## 简介

Some words of wisdom I came across this week around startups choosing not to work on scalability too early.

## 正文

"You are not Facebook, Google, or Uber; you don't have their scalability challenges. Then why do you use shiny toys like GraphQL, microservice meshes, heavy Kubernetes configs, or spend too much engineering resources when open source or commercial solutions are available - like analytics, data analysis, charting, etc." These are some of the questions I ask startup/scaleup technical teams. And usually, I don't get a good answer and seems a lot of teams are just solving problems they don't have. However, this is a dangerous path for a startup/scaleup with limited resources and a limited runway. Focusing too early on scalability, while you are still validating your product can kill your company, since you are focusing on the wrong problems. Early on, every startup must focus on finding its ideal customer profile and market fit. Scalability challenges (if the startup survives) will come after that, not before.

Scaling was challengeing 10 years ago, nowadays its pretty easy to use tools like lambda functions and high throughput databases like dynamodb or redis. It doesn’t require extra effort so its good idea to use such a tools from day one.

In my experience people usually learn it when they get burnt. When I ask why are you doing this complicated architecture the usual answer is because when we become big we will be ready. Well spending your time on the wrong problem is unlikely to help you "become" big. Or the other one I have heard is "by investing in early on we get to iterate faster, because we are prepared. This is typically just a wrong perception or at least I am yet to see an example where it is true.

[Jamie Brown](https://uk.linkedin.com/in/ukjbrown?trk=public_post_comment_actor-name)2y

Personally I wouldn't put GraphQL alongside your other examples. From my experience, GraphQL doesn't add any complexity, nor is it any less suitable for a small application than it is for a large scale one. Have you had a different experience?

100%! The amount of times engineering teams just want to use Microservices when it's a B2B business that only has around 100 clients and can potentially scale to 1000 is baffling. Why not use monoliths for it? Why not build things that are fit for purpose?

[Adrien Pujol](https://ae.linkedin.com/in/apujol?trk=public_post_comment_actor-name)2y

Like everything, I think the right answer is somewhere in the middle, a healthy approach to avoiding unnecessary technical debt at the beginning can save you down the line as much as an over engineered architecture can kill you later if it’s too opinionated (or crappy).

[Peter Bryant](https://nz.linkedin.com/in/peterbryant?trk=public_post_comment_actor-name)2y

I can't count the number of customers we have had that demand facebook-level scalability from day 0 that fail to ever launch anything. Invariably the customers that launch with a single VM, scale up to a whole server, and then re-architect things to scale across multiple servers (and even multiple data centers) are the ones who succeed in building products that their customers want.

[John T.](https://www.linkedin.com/in/johntidwellmba?trk=public_post_comment_actor-name)2y

Viewed purely from a technical standpoint, this makes all the practical sense in the world. However, a technical team building a solution seldom run the business, except firms like Facebook, etc. And while it is easy to say the technical team should educate the business on technical debt, it is much more difficult in practice. So, what happens in reality? The early "proof of concept" gets in the hands of salespeople who are compensated on a commission basis, and soon it is in production with live customers, which it was never architected for. Now the technical team goes to management and asks for 36 months and a few million dollars to refactor the code so that it is secure and scalable, only to be told no. I inherited a platform at a previous employer, where this exact scenario had played out. And in my 30+ year IT career, every IT leader I have ever met and had this conversation with, had their own version of this story. What technical teams are trying to do when they over-engineer, is build a solution that can handle success and securely scale. Is there a more efficient way? Sure. Does that solution involve just the technical teams building the solution? No.

GraphQL is the odd one here. Regardless of my experience supporting GraphQL APIs I can’t think of a single reason why it would positively affect scaling.

[Hugo Lu](https://uk.linkedin.com/in/hugo-lu-confirmed?trk=public_post_comment_actor-name)2y

Best thing I’ve seen on LinkedIn all week

[See more comments](https://www.linkedin.com/signup/cold-join?session_redirect=https%3A%2F%2Fwww%2Elinkedin%2Ecom%2Fposts%2Fvassil-popovski-38544a_you-are-not-facebook-google-or-uber-you-activity-7209281234160537603-baWL&trk=public_post_see-more-comments)

But but, how am I going to create a user if I don't have a micro service for setting user password, a microservice for setting user address, a Kafka event bus with 3 microservices for sending an email, slack and SMS notification for creating users and a microservices based on a document database for storing snapshots of the user creation form? You are telling me there is a better easier way to do this? Blasphemy/s