Approaches to prevent database slowdown when another process is hitting it hard I'm a developer not a dba, but this task was given to me...
One of our databases is hit hard by a process which reads and modifies hundreds of thousands records onece or twice a day, during the time this process is running our other services who rely on this database get very slow.
What are some &quot;common&quot; approaches to solve this kind of problems?
Things I have thought that could work:

Using &quot;NOLOCK&quot; in the read queries
Using a cache service in front of the database, like Redis
Using database redundancy

My questions are: Could any of these 3 options works? and if so, what kind of results can I expect. What other options do I have?
As others have suggested, the problem you've outlined is very open-ended.  However, I can offer one general solution which you may not have considered: break up the intensive operation into smaller batches.  This will keep locks brief, reducing the risk of deadlocks, may reduce the amount of memory and temp space used, and may give the server enough headroom to cope while you do root cause analysis.
For example, if your overnight operation deletes a large number of records, you can instead run DELETE TOP (10000) FROM X WHERE [blah blah] in a loop while @@NUMRECORDS &gt; 0.  You could throttle this by inserting a delay between executions.  Note that the total CPU cycles used will probably be greater with this approach; possibly dramatically greater, depending on the details of the queries involved.  If your server is short on memory, this approach could lead to thrashing your buffer pool (the cache recently-read or -modified records, held in memory when possible).  Test carefully before promoting any change to production, and be ready to halt and revert if it negatively impacts performance.