Azure Redis Cache and RedisJSON, possible alternatives

I am looking into using Azure Redis Cache for one of our applications. We need to store pure JSON, which the best practices section clearly recommends against, under certain circumstances. I am very new to Redis, and I am researching possible patterns for us to fulfill our requirements, and I am unsure if my approach violates those best practices.

The pattern I want to implement is this:

1. A change occurs to an item in a Cosmos database
2. The change feed is parsed for updated items
3. The updated item is serialized and written to Redis
4. When the system is later queried, first look for a cached item. Retrieve and de-serialize if present. If not present, query Cosmos.

The SET and the GET would take place in two completely separate parts of the application. There would never be a scenario where I would retrieve, modify and set, since a Cosmos document acts as an intermediate and can never trigger simultaneous writes. When querying the system, the expectation is always that the cache is up to date if a document exists there.

What I can’t really figure out is if my approach runs the risk of data loss mentioned:

Worse yet, many applications would just GET the entire JSON string, deserialize it, manipulate it, re-serialize and SET it again at the application. This is an anti-pattern. There is a very real risk of losing data with this method.

They go on to suggest RedisJSON, which must be activated on the database level.

Unfortunately, this does not seem to be possible with Azure Redis Cache, or at least I can’t find any documentation or any option to do this whilst creating the resource nor while it has been created.

1. Is it possible to use RedisJSON with Azure Redis Cache?
2. If not #1, are there any alternative recommended approaches to store JSON data with Redis, or is my suggested approach a possible solution?

Update

I solved this by listening to change feeds of the containers I wanted to cache in an Azure Function. This pattern has one single application instance ever writing one unique document, and the reading happens completely separately and never changes the cached value.

The change feed receives the entire document if it is inserted or updated, but not deleted. Thanks to receiving the entire document it is easy to invalidate the cache under certain conditions or adding a soft-delete value to remove it entirely.