Making note of cache stores in documentation.

Signed-off-by: Eric Peterson <ericpeterson@spotify.com>
2021-05-21 17:23:54 +02:00
parent 3a4c45df1f
commit dda070442e
2 changed files with 16 additions and 0 deletions
@@ -113,6 +113,7 @@ json
 jsonnet
 jsx
 Kaewkasi
+Keyv
 Knex
 kubectl
 kubernetes
@@ -182,6 +182,21 @@ work but
 [aren't tested as fully](https://github.com/backstage/backstage/issues/2460)
 yet.

+## Cache
+
+The Backstage backend and its builtin plugins are also able to leverage cache
+stores as a means of improving performance or reliability. Similar to how
+databases are supported, plugins receive logically separated cache connections,
+which are powered by [Keyv](https://github.com/lukechilds/keyv) under the hood.
+
+At this time of writing, Backstage can be configured to use one of two cache
+stores: memory, which is mainly used for local testing, and memcache, which is
+is a cache store better suited for production deployment. The right cache store
+for your Backstage instance will depend on your own run-time constraints and
+those specified by the plugins you're running.
+
+Contributions supporting other cache stores are welcome!
+
 ## Containerization

 The example Backstage architecture shown above would Dockerize into three