diff --git a/slides/k8s/operators-design.md b/slides/k8s/operators-design.md
index d259303b..9a02f2b8 100644
--- a/slides/k8s/operators-design.md
+++ b/slides/k8s/operators-design.md
@@ -72,7 +72,7 @@
 
 - Do we need to store state? If so, where?
 
-  - the Kubernetes API can store state that is small and doesn't change much
+  - state that is small and doesn't change much can be stored via the Kubernetes API
     <br/>
     (e.g.: leader information, configuration, credentials)
 
@@ -82,6 +82,23 @@
 
 ---
 
+class: extra-details
+
+## What can we store via the Kubernetes API?
+
+- The API server stores most Kubernetes resources into etcd
+
+- Etcd is designed for reliability, not for performance
+
+- If our storage needs exceed what etcd can offer, we need to use something else:
+
+  - either directly
+
+  - or by extending the API server
+    <br/>(for instance by using the agregation layer, like [metrics server](https://github.com/kubernetes-incubator/metrics-server) does)
+
+---
+
 ## Bottom-up approach
 
 - Start with existing Kubernetes resources (Deployment, Stateful Set...)
diff --git a/slides/k8s/operators.md b/slides/k8s/operators.md
index b92b0b52..fdf6bbf6 100644
--- a/slides/k8s/operators.md
+++ b/slides/k8s/operators.md
@@ -83,7 +83,7 @@ Examples:
 
   Examples: ElasticSearch, MongoDB ...
 
-- Systems that depend on other non-trivial systems
+- Systems with complex dependencies (that are themselves managed with operators)
 
   Examples: Flink or Kafka, which both depend on Zookeeper