So, if an account is restricted to use Developer Console, does that mean each event in sf ui will be in single transaction (assuming that there is no code that updates multiple records when a certain record is inserted or updated)?
- Restricting an account to use the developer console is not possible.
- Each DML conducted through the UI will initiate a transaction that may or may not affect multiple records. If you have an Apex trigger that deletes a related object when you do something to another object, then your transaction starts with a DML on a single object, but will in total contain multiple DMLs. That's where you start to think about the governor limits (how many queries and DMLs are allowed per transaction).
I am a customer.. I have updated the record in salesforce UI.. so it's not possible for me to trigger a bulk transaction?
That depends on what your record update does, and which automation you have in place. If you have no automation in place, then in general every update conducted through the UI will be a single transaction that processes the update for a single record. Like in my example above, if you have an automation that does update related records then your transaction will start with that update DML but will process other things too. And everything will happen in the same transaction (unless you have something running asynchronously).
It is quite common to have a requirement like "update this record, and then process all other records asynchronously". In this kind of scenario, your main transaction does the update and, at the end, fires an asynchronous process to do the bulk update (depending on the number of records, you won't be able to do the update in the same transaction - for example if you want to update millions of records).
Then how about if the same account is login to multiple computers and the user updated the same record at the same time.. is the update of each record in the same transaction or separate governor limits?
First of all: sharing an account is a violation of the MSA with Salesforce. Secondly: in this scenario whoever manages to get the request first on the server will likely lock the record for updates from others. Others' requests will still try to be processed but will have to wait until the previous one finishes, since they are all trying to modify the same row in the database. What might also happen in this scenario is that the transactions take longer to process and then the other transactions at the end of the queue will fail (because of the 10 seconds rule in the governor limits).
To better illustrate, imagine you have three users updating the same record. Because of the amount of automation in the org, the transaction takes four seconds to complete in total. So all transactions seemingly start at the same time, but just one of them manages to get a lock on the record. The other two are in the queue to be processed next. All transactions' time start at almost the same time, so the first one takes four seconds, but the second transaction really manages to continue only after the first is completed, so the second transaction takes eight seconds total. The same happens for the third transaction, but because its total execution time would be twelve seconds, which is longer than the ten second-limit, it fails.