docs: fixed spelling/typos in docs

Author: HarrisonTCodes

docs/k8s.md

@@ -3,7 +3,7 @@
 Simple Kubernetes manifests can be found in the `k8s` folder. The configuration there, as well as the instructions in this document, are designed for a local bare-metal cluster (particularly using minikube) for testing how the distributed system behaves across multiple replicas.
 
 ## Configuration
-There are 3 mainfests in the `k8s` folder:
+There are 3 manifests in the `k8s` folder:
 - `app.yaml`: The `Deployment` and `Service` for the `session-queue` app
 - `redis.yaml`: Simple Redis `Deployment` and `Service` for the `session-queue` replicas.
 - `config.yaml`: Environment variable configuration for `session-queue` with some sensible testing defaults.
@@ -38,7 +38,7 @@ kubectl logs {pod} --follow
 ```
 
 ## Production
-As mentioned, the out-the-box mainfests are made for local development testing. There are various changes that could/should be made for a production-ready k8s deployment, including:
+As mentioned, the out-the-box manifests are made for local development testing. There are various changes that could/should be made for a production-ready k8s deployment, including:
 - Pushing the image to a remote registry and not using `imagePullPolicy: Never`
 - Using a `Service` of type `LoadBalancer` to expose the deployment (particularly if on a cloud environment)
 - Storing the JWT secret outside of config/source control, and using something like [ESO](https://external-secrets.io/latest/) to inject it

docs/system.md

@@ -9,8 +9,8 @@ The server keeps track of two dynamic values, which are just integers in Redis:
 - The last queue position in the current active window  
 
 Based on static variables (namely the window size and number of active windows), each ticket's state can be derived from its own position, as either:
-- Expired: the ticket was issued before the current acive windows and is no longer active
-- Active: the ticket is within the actve windows (ie less than the last active queue position, and greater than the lower bound)
+- Expired: the ticket was issued before the current active windows and is no longer active
+- Active: the ticket is within the active windows (ie less than the last active queue position, and greater than the lower bound)
 - Waiting: the ticket position is greater than the last active queue position and not yet active
 
 The last active queue position can then be incremented, by the window size, at a regular interval, thus sliding the window and processing the next batch of tickets.
@@ -33,4 +33,4 @@ To interact with the system as a user, 2 HTTP endpoints are exposed:
 ## Considerations
 By storing state on the client-side with JWTs and only integers server-side, the system is scalable and can handle very large queues.
 
-For slow queues where the window is attempting to increment faster than people are joining queues (ie the next latest active queue position is greater than the current queue position), window increments are skipped until the queue catches up to avoid issuing expired tickets. This, however, leads to the edge case of a user requesting a ticket after a skipped incremement and the window almost instantly incrementing after, invalidating it. To avoid this, multiple active windows are recommended (at least 2), to allow spill-over from the previous batch whilst still preventing bursty traffic from very old tickets.
+For slow queues where the window is attempting to increment faster than people are joining queues (ie the next latest active queue position is greater than the current queue position), window increments are skipped until the queue catches up to avoid issuing expired tickets. This, however, leads to the edge case of a user requesting a ticket after a skipped increment and the window almost instantly incrementing after, invalidating it. To avoid this, multiple active windows are recommended (at least 2), to allow spill-over from the previous batch whilst still preventing bursty traffic from very old tickets.