Usage as cache / data store?

Question

I've read of people using Elasticsearch or Solr as a caching layer for their application, which on the surface at least makes a lot of sense: the search engine is fast, and often you've got all your data in there anyway. I imagine that the appropriateness
of this is primarily an architecture question, but is there anything specific to Azure Search that would make using it as a caching layer an especially bad idea?
Thanks!
I'm not sure how much context that question requires, but for what it's worth: we make a kind of social CRM/intranet product, so our data consists of contacts, employees, projects, companies, and social posts/comments (which can include uploaded documents).
Currently, most of this is pulled from a (fairly normalized) SQL database, or from an small-ish in-role Azure cache. We want to implement a great search feature across all this data, but because the usage of this data often requires some complex joins or formatting,
we also want to implement a larger cache to keep all of our data in a denormalized form. So if not Azure Search or Elasticsearch, we're probably looking at Redis or maybe even a NoSQL like Mongo.

Answer 1

Yes, we do see many cases where it's natural to use Azure Search (or some other search stack) both for search and for serving other queries/content as well, since as you say you already have the data there.
One particular pattern we see is having an operational store such as SQL which stays normalized (and sometimes even on-premises) and the denormalized Azure Search index is created out of it. Then online projections (websites, mobile apps, etc.) are served
entirely from the Azure Search index.
Whether you should use Azure Search or a different cache depends on your access patterns. If you need full-text search (e.g. basic keyword search and potentially things such as linguistics, ranking, etc.) then Azure Search could be a good fit. If you only
retrieve data on exact queries and you won't need search in the future, you could use Azure Search but other stores might offer other advantages (e.g. Redis cache or DocumentDB).
This posting is provided "AS IS" with no warranties, and confers no rights.