Am I right that switching programming languages will have little impact on the scalability of a CRUD API?

Question

An external consultant to our team advised us to rewrite our SaaS offering (essentially a CRUD API) in .NET because this is more "scalable" than using Node.js (or Ruby on Rails, Flask, etc.). By that they seem to mean that a backend API written in .NET will handle the growing performance requirements much better than a backend API written in a scripting language like JavaScript, Ruby or Python, once the startup scales to tens of millions of users (an ambitious dream).

To me this seems wrong. The performance of a CRUD API should be completely dominated by the choice of architecture and hardware instead of the programming language.

Am I right that switching programming languages will have little impact on the scalability of a CRUD API?

Answer 1

There's a good video (warning, contains really a lot of swearing, but worth it) that will give you a good basis for arguing against this consultant... Solving Imaginary Scaling Issues (at Scale), by Laurie Voss at DinosaurJS conference.

The crux of the matter is that the consultant hasn't identified any actual, specific problem, so there's simply no way to know if the solution will fix any problem.

(Rehashing some territory from other answers here...) Scalability when used in this vague context means many things, horizontal scaling, vertical scaling, team scaling, etc. But they aren't the same, and when you actually need to fix something then you need to identify the real, underlying problem as specifically as possible.

If your general problem (scalability) was that your leg hurts, then one solution (new language) might be a cast, another solution (api change) might be antibiotics, etc., but you really have to know what the underlying cause is, e.g. broken bone, infection,..., (cpu usage, network times) to know which cure will actually do anything for you. And there are costs to using unnecessary cures, even in the best case they are simply expensive to implement, in the more common case they actually cause other problems when inappropriately used.

Your consultant should be providing you with real data about your system showing what the underlying problem is and why this will fix it. If you were currently experiencing the problem in the wild then I would want some metrics such as memory usage from prod, metrics from the ticketing system showing that devs are spending a long time struggling with language issues, whatever. Since this doesn't actually appear to be live now, I would still want some study with simulated load in non prod or specific areas of the code that will become difficult to work on or whatever. About the only time this random opinion nonsense is sort of OK is if the proposed solution is very low/no cost, like if the system doesn't even exist yet, but then I'd be more interested in opinions of the people who may actually maintain it one day, as opposed to a consultant who will be waving goodbye and leaving all the work with other people.

(I am on my fifth or sixth re-watch of this video, my management is notoriously buzzword happy and more influenced by outside opinions vs on the ground devs who could easily point out several problems which are low hanging fruit for fixing, so I have seen many of these ideas being proposed with actual seriousness.)

Answer 2

At a global level, you're wrong - language does matter, or at the very least you will spend more $$$ on compute if you write it in a less computationally efficient language.

While I'm not at liberty to go into details, I work for Disney Streaming and it's well known we're a Scala shop. If our highest scale services were written in (say) Node.js rather than a JVM language, we would be spending significantly more each month on the containers/servers we need to run our services. Our services are often compute bound, so there does just come a point at which raw language efficiency does matter.

That all said, you don't have as many users and as much concurrency as we do. If you had to run twice as many servers, would that have a significant impact on your business? If not, you're probably right to keep working in the languages your team is used to.

Answer 3

You should remove this consultant from touching any of your system. A consultant suggesting a complete rewrite of an application in a different language are going to cause a lot of damage to the system and to your company.

Consultants often make these kind of expensive, vague suggestions; the real reason they are suggesting to rewrite your application in their preferred pet language is to lock you in into their service, not anything for your own benefit. Find a different consultant that fits into your system, not a consultant that wants to retrofit your system into their world.

Most web applications won't scale better when rewritten in a different language, because the majority of web applications spend their time in database or API calls, which are already written in fast languages. You'll get better miles for your effort by optimising the uses of those database calls than by rewriting the same logic in a different language. And even when there's a good reason for rewriting a slow calculation in a different language, you usually only want to rewrite a very small part of the performance sensitive component in a faster language, while keeping the bulk of your application in easier to use scripting language.

When it comes to scalability, there are many different metrics.

In the vast majority of cases, the speed of the language matters none to scalability, designing good system architecture is where you need to design the system to scale.

• making your application stateless, so your application can be scaled out to a cluster rather than a single machine

• rearchitecting parts of the system that can run as edge service (close to the user) or as asynchronous tasks (not tied to request-response cycle)

• modularity so multiple developers can work concurrently on the code base

• writing tests so that anyone can confidently deploy their changes and not fear breaking anything

• API designs that suits the use case

• database design, as well as using multiple databases/data store that's appropriate for your use case

• etc

These are all scalability improvements that will have much better return on investment than rewriting an application in a different language.

And in most cases when you want to rewrite a performance sensitive parts in "faster" language, the language you should be using isn't going to be .NET, but usually a systems programming language like C/C++ or Rust, which you can then FFI call from your existing application. .NET is too much still a high level framework that won't actually gives you the scalability or performance benefit of a rewrite.

Answer 4

With a simple CRUD api, your bottlenecks are probably the network and the database. So the code you use for mediating and translating between the two layers is probably not that performance-critical.

But is it really? How much business logic do you have in the application? How computationally expensive is that business logic? These were rhetorical questions, because this is for you to determine through analyzing what you actually want to do, prototyping it and doing benchmarks.

Answer 5

By that they seem to mean that a backend API written in .NET will handle the growing performance requirements much better than a backend API written in a scripting language like JavaScript, Ruby or Python, once the startup scales to tens of millions of users (an ambitious dream).

Are you sure about that?

"Scalable" could have multiple meanings here. Not just in the computational runtime performance, but also for growing out your engineering organization and being able to add functionality in parallel without too much friction. Statically typed languages tend to fare better there, since the type checking becomes more valuable as the codebase grows and it becomes impossible for every/any engineer to know the entire system in detail.

Because your infrastructure costs for a CRUD api are going to be a tiny fraction of your labor costs until the product is very mature and widely used. The consultant might be more worried about that than how linearly your server to request trends are.

Answer 6

The scalability of a CRUD application is mainly linked to the completion of elementary transactions.

Filling in a couple of variables and calling some functions is only a fraction of the time needed to lock a record in the database, write an operation in the journal (in case a rollback is needed), update the records on the disk, update the indexes (i.e inserting a new value and balancing the btrees).

So, with Node, most of the time will be spent in the database part. If you switch to C++, Go, or C, this part of the job will not change drastically, even if the speed of the preparation for the database calls would be faster.

Another scalability issue is the ability to increase the throughput by reducing the locks. For example, if your application reads a table to find the next free ID, all the processes that concurrently insert a new value would be sequentialized waiting for the locks to be freed. You could even write your code in optimised assembler: the scalability would be 0. So don’t diddle code, find better algorithms.

Last but not least, scalability will also depend on the possibility to split the database across several processing nodes (distributed database) instead of relying on a single instance. This is very challenging, and again, the preparatory steps in native languages are insignificant compared to the DB coordination effort.

Answer 7

I don't have the rep to comment yet, and the others here have addressed the critical points:

1. you need to be presented with data demonstrating that you do have a compute bottleneck,
2. the amortised cost of rewriting is lower than the cost of just adding more compute/memory (and managing that additional hardware), and
3. that the incentives of the external consultant align with your business, not with generating more work from you, which will be proved by 1 and 2 above.

However, there does appear to be a 10x+ performance boost available by switching from Express (NodeJS) to actix(Rust) or one of the .net frameworks:

https://www.techempower.com/benchmarks/#section=data-r20&hw=cl&test=composite

Answer 8

The language matters for several reasons. The first ones that come to mind are:

• The language may bring with itself paradigms and special implementations of the common design patterns that will eventually affect the design.
• The APIs and the available libraries will affect the architecture and the design even more.
• On a minor note, you can add that there is still some difference in the performance of the different runtime environments.

Answer 9

The consultant probably uses "scalable" as a buzzword devoid of meaning.

Scalable means (simply put) that a system can cope with significantly increased demand without the cost per user going up or the performance per user suffering.

Programming language choice will not affect scalability, since the difference in performance between languages is a constant factor. Let's say language A is 50x faster on average than language B. This factor will remain constant when the number of users increases. So it doesn't affect scalability.

Scalability problems are typically due to architectural bottlenecks and bad algorithms - both of which are issues independent of programming language.

Answer 10

Programming language / framework does matter.

Even within .NET. ASP.NET Core vs. .NET Framework can see a 7 times speed increase for tasks such as serialisation and deserialization and simple string validation such as StringStartsWith. See: .NET Core vs .NET Framework: Testing Performance

Taking into account other languages, their specific overheads, compiled vs scripted, etc. all add up.

Key information from the above site:

.NET Core featured in all my tests much faster than the full .NET – sometimes 7 or even up to 13 times faster. Choosing the right CPU architecture can dramatically change the behaviour of your application, so the results gathered from one architecture can be invalid on the other and vice versa. For example – if your .NET Core application performs much SHA256 hashing computations, then the best option would be to use AMD Zen-based servers instead of Intel-based ones. So to sum up – if performance is a significant factor in your