Live Data Web Application Design

I'm about to begin designing the architecture of a personal project that has the following characteristics:

Essentially a "game" containing several concurrent users based on a sport. Matches in this sport are simulated on a regular basis and their results stored in a database. Users can view the details of a simulated match "live" when it is occurring as well as see results after they have occurred. I developed a similar web application with a much smaller scope as the previous iteration of this project. In that case, however, I chose to go with SQLite as my DB provider since I also had a redistributable desktop application that could be used to manually simulate matches (and in fact that ran as a standalone simulator outside of the web application). My constraints have now shifted to be only a web application, so I don't have to worry about this additional level of complexity.

My main problem with my previous implementation was handling concurrent requests. I made the mistake of using one database (which was represented by a single file on disk) to power both the simulation aspect (which ran in a separate process on the server) and the web application. Hence, when users were accessing the website concurrently with a live simulation happening, there were all sorts of database access issues since it was getting locked by one process. I fixed this by implementing a cross-process mutex on database operations but this drastically slowed down the performance of the website. The tools I will be using are:

ASP.NET for the web application. SQL Server 2008 R2 for the database. probably with an NHibernate layer for object relational mapping. My question is, how do I design this so I will achieve optimal efficiency as well as concurrent access? Obviously shifting to an actual DB server from a file will have it's positives, but do I need to have two redundant servers--one for the simulation process and one for the web server process?