docs: improve docs on caching

docs/content/getting-started/production-best-practices.mdx

@@ -29,7 +29,9 @@ The following list outlines best practices for running OpenFGA in a production e
 
 We recommend:
 
-1. Turn on caching via the flag `--check-query-cache-enabled`. This will reduce latency of requests, but it will increase the staleness of OpenFGA's responses. (The TTL is configurable).
+1. Turn on caching in Check API via flags. This will reduce latency of requests, but it will increase the staleness of OpenFGA's responses.
+   1. `--check-query-cache-enabled`. This caches Check sub-problems for a specified TTL (default of 10 seconds). For example, if you have a relation `define viewer: owner or editor`, and the query is `Check(user:anne, viewer, doc:1)`, we'll evaluate the `owner` relation and the `editor` relation and cache both results: `(user:anne, viewer, doc:1) -> allowed=true` and `(user:anne, owner, doc:1) -> allowed=true`. The cache is stored in-memory; the cached values are overwritten on every change in the result, and cleared after the configured TTL.
+   2. `--check-iterator-cache-enabled`. This caches rows from the database, for a specified TTL (default of 10 seconds).
 2. Prefer having a small pool of servers with high capacity (memory and CPU cores) instead of a big pool of servers, to increase cache hit ratios and simplify pool management.
 3. Turn on metrics collection via the flags `--metrics-enabled` and `--datastore-metrics-enabled`. This will allow you to debug issues.
 4. Turn on tracing via the flag `--trace-enabled`, but set sampling ratio to a low value, for example `--trace-sample-ratio=0.3`. This will allow you to debug issues without overwhelming the tracing server. However, keep in mind that enabling tracing comes with a slight performance cost.

docs/content/getting-started/tuples-api-best-practices.mdx

@@ -19,7 +19,8 @@ import {
 The following list outlines some guidelines and best practices for using <ProductName format={ProductNameFormat.ShortForm}/>:
 
 - Do not store Personal Identifiable Information in tuples
-- Always specify authorization model ID whenever possible
+- Always specify authorization model ID in requests
+- Always specify the desired consistency in requests
 
 ## Do Not Store Personal Identifiable Information in Tuples
 
@@ -29,14 +30,20 @@ You can use any string for user and object identifiers, however you should not i
 The documentation and samples uses first names and simple ids to illustrate easy-to-follow examples.
 :::
 
-## Always specify authorization model ID whenever possible
+## Always specify authorization model ID in requests
 
 It is strongly recommended that authorization model ID be specified in your Relationship Queries (such as [Check](./perform-check.mdx) and [ListObjects](../interacting/relationship-queries.mdx#listobjects)) and Relationship Commands (such as [Write](./update-tuples.mdx)).
 
 Specifying authorization model ID in API calls have the following advantages:
 1. Better performance as <ProductName format={ProductNameFormat.ShortForm}/> will not need to perform a database query to get the latest authorization model ID.
 2. Allows consistent behavior in your production system until you are ready to switch to the new model.
 
+## Always specify the desired consistency in requests
+
+It is strongly recommended that you specify the `Consistency` value in each individual request, depending on whether you prefer speed (MINIMIZE_LATENCY) or correctness (MAXIMIZE_CONSISTENCY). The default is MINIMIZE_LATENCY.
+
+In addition, if speed matters to you, we recommend that you follow [Production Best Practices](./production-best-practices.mdx).
+
 ## Related Sections
 
 <RelatedSection