What happens if several users update different accounts on the same time (user 1- Account a, user 2 - account b, user 3 - account c)? Is there one trigger execution that handles all records or multiple trigger execution for each record?
The Account trigger will execute exactly three times (assuming no recursion). For each execution,
Trigger.new will contain one Account, and the running user will be the user who updated that record. In synchronous Apex code, changes executed by multiple users are never aggregated: each user initiates a separate transaction, within which transaction that user is the running user. That means that any automation which executes, such as triggers, Processes, Workflow Rules, and so forth, execute as that user.
is there an order which get fires first? or are they handled in parallel?
Simultaneity is kind of tricky; in practice, it's near-certain that one or the other of the updates will in fact arrive first, but they'll execute in parallel with one another. Assuming the Accounts are distinct and are unrelated, the transactions might commit in any order depending on how long they take to process, which could vary since different logic might execute based on the data involved.
If the records are, for example, related in a way that would cause an update to record A to lock record B (see the record locking cheat sheet, warning, PDF link), portions of the transaction may briefly block to serialize access to the common resource. If the lock lasts too long, one or more of the transactions may fail because it can't acquire the lock in time; this would result in an error message (e.g.
if they are handled in parallel and there are updates on the same record how is it processed (user 1- Account a, user 2 - account a, user 3 - account b)
There's no effect on the unrelated record.
The Salesforce UI does collision detection. If User 2 starts their edit session and User 1's changes go through before they click save, User 2 will see an error.
In Apex, you can use the
FOR UPDATE SOQL clause to lock records you want to update, to ensure that access to those records are serialized and that you don't inadvertently overwrite changes made by another transaction or operate based on bad data.
This causes the same type of structure as noted above when related records are locked by an update: the first transaction to get the lock holds it until it commits successfully, and any other transaction wanting to get the lock has to wait. A
QueryException is thrown if the lock cannot be acquired in time.
n.b. there can be a fair amount of complexity around record locking behavior - search SFSE to find some quite interesting questions about how to resolve locking issues.