Update the memory-management design document

Signed-off-by: Richard Wall <richard.wall@venafi.com>

design/20221205-memory-management.md

@@ -90,6 +90,22 @@ This proposal suggests a mechanism how to avoid caching cert-manager unrelated `
 
 - use the same mechanism to improve memory consumption by cainjector. This proposal focuses on controller only as it is the more complex part however we need to fix this problem in cainjector too and it would be nice to be consistent
 
+  > 📖 Update: In [#7161: Reduce memory usage by only caching the metadata of Secret resources](https://github.com/cert-manager/cert-manager/pull/716199)
+  > we addressed the high startup memory usage of cainjector with metatdata-only caching features of controller-runtime.
+  > We did not use the split cache design that was implemented for the
+  > controller, and this contradicts the goal above: "use the same mechanism to
+  > improve memory consumption by cainjector ... to be consistent".
+  > Why? Because the split cache mechanism is overkill for cainjector.
+  > The split cache design is designed to reduce memory use **and** minimize the
+  > ongoing load on the K8S API server; which is appropriate for the controller
+  > because it has multiple controller loops each reading Secret resources every
+  > time a Certificate is reconciled.
+  > It is not necessary for cainjector, because cainjector reads relatively few
+  > Secret resources, infrequently; `cainjector` only reads Secrets having the
+  > `cert-manager.io/allow-direct-injection` or Secrets created from
+  > Certificates having that annotation. And it only reads the Secret data once
+  > during while reconciling the target resource.
+
 #### Must not
 
 - make our controllers less reliable (i.e by introducing edge cases where a cert-manager related event does not trigger a reconcile). Given the wide usage of cert-manager and the various different usage scenarios, any such edge case would be likely to occur for some users