How to architecturally organize a search microservice in golang?

Question

MongoDB

There was an idea to organize the search in the catalog of digital goods as a separate microservice based on Go and Redis. Go acts as an API that looks out through a reverse proxy and takes data from the mongo, or from the redis cache if it exists.

Does it make sense from an architectural point of view?

Answer 1

Redis as a cache is relevant for "single-core" languages ​​like node/python/php. There are big problems with multi-threaded memory access, so instead of memory they use key-value (you can still remember memcached). And if you have golang - so why radish? Use the cache in memory, it will still work an order of magnitude faster due to the lack of network interactions on cache hits.

Answer 2

All right. The most common practice.
Only instead of Redis you can also use Memcached (faster). https://medium.com/@Alibaba_Cloud/redis-vs-memcach... It
is also possible to use in-memory k/v storage as Sergey Tikhonov advises , but in this case, when the service is restarted (errors, etc.) data in the cache will be lost and it will take time to warm up the cache.