transaction log in RAM or physical file?
You can find a pretty comprehensive guide to this question here, but to summarise, SQL Server will not return control to the application that committed a transaction until that transaction has been hardened to disk. Specifically, once it has been hardened to the transaction log file, control can be returned.

The data, at this point, may not be hardened into the data file, it may still be in the data buffer cache, but because it has been hardened into the transaction log then database recovery, in the event of a failure, can recover this transaction and persist the changes safely.

There is a log buffer cache in memory used to reduce the performance impacts of the sequential writes to transaction logs. The buffer is flushed to disk on several conditions, but one of them is a transaction commit. Until this data has been hardened, control is not returned to the caller, so even if you have a failure during this buffer flush the transactional consistency is maintained because this transaction is not yet considered committed. You will lose the data changes in that transaction, but as it was not committed, your application would already consider those changes lost as the commit was never completed.