You are correctly pointing out a race condition.
Cache-aside, as described here and here, is an imperfect abstraction that is not appropriate for all data storage use cases.
Consistency. Implementing the Cache-Aside pattern does not guarantee consistency between the data store and the cache. An item in the data store may be changed at any time by an external process, and this change might not be reflected in the cache until the next time the item is loaded into the cache. In a system that replicates data across data stores, this problem may become especially acute if synchronization occurs very frequently.
This text refers to the problems when someone modifies the data store without informing the cache its need to invalidate. (The pattern describes the need for an appropriate eviction policy, which is intended to limit the lifetime of data errors.)
Yet, the race condition you are pointing out could occur even if all clients are playing by the rules. When the race condition happens, stale data will be deposited in the cache and remain there until it is otherwise evicted (by standard (e.g. time-based) eviction or because data at that key is one again updated, and this time perhaps without the race.)
Serving some stale data alongside up-to-date data is a worse kind of consistency breach than merely returning stale information that was at least fully correct taken together at one point in time (a snapshot). This is sometimes called a form of read or write skew.
Also I would like to know if some changes can be made in the pattern to avoid this problem.
A problem with this pattern is that it spreads a single responsibility (data storage; holding state) across multiple components. So, a way to fix the race condition you're pointing out is to change the model so that the cache is a first-class entity having the full responsibility for both reading and writing the data. The clients would ask the cache for data, the cache, when needed, would fetch the data from the data store and return it to the clients. The clients would inform the cache of updates, and the cache would update the data store. The cache would then be in a position to provide the appropriate synchronization so it could avoid race conditions.
Ultimately, this pattern is useful for data that doesn't change often, and for data storage that doesn't depend on set consistency / transactions over multiple keys. For example, it might work for certain kinds of document stores, such as a music library, especially if the library is mostly appended to, keys are never updated, and occasionally documents are deleted but it is ok (from the business perspective) to continue to serve them for the eviction duration after they are deleted.