How does Rails handle multiple incoming requests?

Question

How does Rails, handle multiple requests from different users without colliding? What is the logic?

E.g., user1 logged in and browses the site. At same time, user2, user3, ... log in and browse. How does rails manage this situation without any data conflict between users?

Answer 1

One thing to bear in mind here is that even though users are using the site simultaneously in their browsers, the server may still only be handling a single request at a time. Request processing may take less than a second, so requests can be queued up to be processed without causing significant delays for the users. Each response starts from a blank slate, taking only information from the request and using it to look up data from the database. it does not carry anything over from one request to the next. This is called the "stateless" paradigm.

If the load increases, more rails servers can be added. Because each response starts from scratch anyway, adding more servers doesn't create any problems to do with "sharing of information", since all information is either sent in the request or loaded from the database. It just means that more requests can be handled per second.

When their is a feeling of "continuity" for the user, for example staying logged into a website, this is done via cookies, which are stored on their machine and sent through as part of the request. The server can read this cookie information from the request and, for example, NOT redirect someone to the login page as the cookie is telling them they have logged in already as user 123 or whatever.

Answer 2

As additional case You could use something like a "puma" multithread server...

Answer 3

In case your question is about how Rails differ users the answer will be that is uses cookies to store session. You can read more about it here.

Also data does not conflict since you get fresh instance of controller for each request

RailsGuides:

When your application receives a request, the routing will determine which controller and action to run, then Rails creates an instance of that controller and runs the method with the same name as the action.

Answer 4

This is achieved using a "session": a bunch of data specific to the given client, available server-side.

There are plenty of ways for a server to store a session, typically Rails uses a cookie: a small (typically around 4 kB) dataset that is stored on user's browser and sent with every request. For that reason you don't want to store too much in there. However, you usually don't need much, you only need just enough to identify the user and still make it hard to impersonate him.

Because of that, Rails stores the session itself in the cookie (as this guide says). It's simple and requires no setup. Some think that cookie store is unreliable and use persistence mechanisms instead: databases, key-value stores and the like.

Typically the workflow is as follows:

• A session id is stored in a cookie when the server decides to initialize a session
• A server receives a request from the user, fetches session by its id
• If the session says that it represents user X, Rails acts as if it's actually him

Since different users send different session ids, Rails treats them as different ones and outputs data relevant to a detected one: on a per-request basis.

Before you ask: yes, it is possible to steal the other person's session id and act in that person's name. It's called session hijacking and it's only one of all the possible security issues you might run into unless you're careful. That same page offers some more insight on how to prevent your users from suffering.

Answer 5

That is guaranteed not by Rails but by the database that the webservice uses. The property you mentioned is called isolation. This is among several properties that a practical database has to satisfy, known as ACID.