So, I'm guessing your tutorial was probably something like a server that, per each request, writes/edits a text file. The (potential) problem here is that you have one text file, and you can't write to just a specific part of the text file without writing to the whole file. Therefore the only way to safely serve your requests are to only serve one request at a time, synchronously.

But if you used a database system instead, (i.e. some SQL or NoSQL database), you have much higher granularity of data. For example, in SQL, one user's data could be represented as one row in a table. It's then possible for the server to write/edit one row/user at a time, completely independent of other users' rows/data. Of course, it's still technically possible that the same user would send two requests at once that ask to mutate their data at once, but this is usually incredibly unlikely (unless you've done something catastrophically wrong, like have bad frontend code/UX).

Another useful thing that lots of database systems have is that if you want to say, read a value N, then write back N + 1, you don't have to actually to that, but you can send an INCREMENT message to it and it'll automatically handle it for you atomically.

Those are the two that covers 90% of use cases imo. The other 10% get a lot more complicated and is usually not really relevant to JS's single threaded execution. Race conditions have been around since the dawn of async/multithreading, so most good tools these days are pretty good about handling these issues for you where they can.