diff --git a/site/content/en/docs/FAQ/_index.md b/site/content/en/docs/FAQ/_index.md
index 545530f7e5..b105b0d61a 100644
--- a/site/content/en/docs/FAQ/_index.md
+++ b/site/content/en/docs/FAQ/_index.md
@@ -184,6 +184,47 @@ This number could vary depending on the underlying scaling capabilities
 of your cloud provider, Kubernetes cluster configuration, and your GameServer Ready startup time, and
 therefore we recommend you always run your own load tests for your specific game and game server containers.
 
+## Architecture
+
+### Can't we use a Deployment or a StatefulSet for game server workloads?
+
+Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) were built for 
+_unordered_, _stateless_ workloads. That is, workloads that are essentially homogeneous 
+between each instance, and therefore it doesn't matter which order they are scaled up, or scaled down.
+
+A set of web servers behind the same load balancer are a perfect example of this. The configuration and application 
+code between instances is the same, and as long as there are enough replicas to handle the requests coming through a 
+load balancer, if we scale from 10 to 5, it doesn't matter which ones are removed and in which order.
+
+Kubernetes [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
+were built for _ordered_, _stateful_ workloads. That is, workloads in which each instance is 
+essentially heterogeneous, and for reliability and predictability it's extremely important that scale up happens in 
+order (0 ,1, 2, 3) and scaling down happens in reverse (3, 2, 1, 0).
+
+Databases are a great use case for a StatefulSet, since (depending on the database), instance 0 may be the primary, 
+and instances 1, 2, 3+ may be replicas. Knowing that the order of scale up and down is completely reliable to both 
+ensure that the correct disk image is in place, but also allow for appropriate synchronisation between a primaries 
+and/or replicas can occur, and no downtime occurs.
+
+Dedicated, authoritative game server workloads are _sometimes stateful_, and while 
+not ordered/unordered, game servers are _prioritised_ for both scale down and allocation for player usage.
+
+Game servers are sometimes stateful, because their state only matters if players are playing on them. If no players 
+are playing on a game server, then it doesn't matter if it gets shut down, or replaced, since nobody will notice. 
+But they are stateful (most often in-memory state, for the game simulation) when players are playing on them, and 
+therefore can't be shutdown while that is going on.
+
+Game Server workloads are also _prioritised_, in that the order of demarcating game servers for player connection 
+and also on game server scale down impact optimal usage of the hosting infrastructure.
+
+For example, in Cloud based workloads, you will want to pack the game servers that have players on them as tightly 
+as possible across as few Nodes as possible, while on scale down, will want to prioritise removing game servers from  
+Nodes that are the most empty to create empty Nodes that then can be deleted - thereby using the least amount of 
+infrastructure as possible.
+  
+So while one might be able to use Deployments and/or StatefulSets to run game server workloads, it will be extremely 
+hard (impossible? 🤔) to run as optimally as a tailored solution such as Agones.
+
 ## Ecosystem
 
 ### Is there an example of Agones and Open Match working together?