From dda070442ed3b01f2a89153752f6466bb86eb77c Mon Sep 17 00:00:00 2001 From: Eric Peterson Date: Fri, 21 May 2021 17:23:54 +0200 Subject: [PATCH] Making note of cache stores in documentation. Signed-off-by: Eric Peterson --- .github/styles/vocab.txt | 1 + docs/overview/architecture-overview.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+) diff --git a/.github/styles/vocab.txt b/.github/styles/vocab.txt index c367fa0a4c..b8f028a2ae 100644 --- a/.github/styles/vocab.txt +++ b/.github/styles/vocab.txt @@ -113,6 +113,7 @@ json jsonnet jsx Kaewkasi +Keyv Knex kubectl kubernetes diff --git a/docs/overview/architecture-overview.md b/docs/overview/architecture-overview.md index 316f066614..1098a3f5f9 100644 --- a/docs/overview/architecture-overview.md +++ b/docs/overview/architecture-overview.md @@ -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