random-number-api

This repository contains a POC REST API that generates a random number. The Github Actions builds the Python application, builds a docker image and pushes the docker image to Docker Hub.

Prototype to Production

1. Scalability & Reliability

Prototype – Single FastAPI container

For the POC, the design is simple by running the API as a single FastAPI container. At this stage, the main goal was to validate the idea and API behavior quickly, without adding unnecessary operational overhead since the service only generates random numbers and doesn’t maintain state.

Production – Kubernetes with autoscaling

For production, I would move this to Kubernetes because the service is stateless. That makes it easy to scale horizontally by running multiple replicas. We can use Horizontal Pod Autoscaling based on CPU or memory to handle traffic spikes automatically. Putting these replicas behind a load balancer improves reliability, so even if a pod fails, traffic is seamlessly routed to healthy ones.

2. Deployment & Infrastructure Strategy

Infrastructure as Code

For infrastructure, I would use Terraform so everything is defined as code. This helps keep the setup consistent across environments and makes changes predictable and auditable. It also reduces manual errors and allows us to recreate or modify resources like VPCs, EKS clusters, and load balancers in a controlled way.

Deployment strategy

For deployments, I would follow a GitOps-based approach using Argo CD. GitHub Actions can handle building and pushing the container image whenever there’s a code change. Helm charts can be used to package and version the Kubernetes manifests, and Argo CD continuously syncs the cluster with what’s defined in Git. This makes deployments more reliable, simplifies rollbacks, and ensures the cluster state always matches source control.

Environment separation

I would also keep separate environments like dev, QA, staging, and prod. This allows us to test changes progressively and reduce the risk of breaking production by catching issues earlier in the pipeline.

3. Security Considerations

• From a security perspective, I would run containers as non-root users to limit the impact of potential compromises.
• Using a slim base image helps reduce the attack surface by removing unnecessary dependencies.
• Network policies can be applied to restrict communication only to what’s required.
• For AWS access, IAM roles for service accounts allow pods to securely access resources without embedding credentials.
• Exposing the service through an ALB with ACM certificates ensures all traffic is encrypted over HTTPS.

4. Observability & Operational Readiness

• For observability, I would use Prometheus to collect metrics and Grafana Dashboards to visualize them, which helps understand system behavior under load.
• Centralized logging makes debugging easier by bringing all pod logs into one place.
• Health check endpoints combined with Kubernetes readiness and liveness probes allow the platform to detect and recover from failures automatically.
• On top of that, alerts on things like high latency, error rates, or frequent pod restarts ensure issues are identified early.

5. Future Evolution & Extensibility

• The design is flexible enough to support future features, like range-based random numbers or authenticated endpoints, without major changes.
• Using versioned APIs allows us to evolve the service while maintaining backward compatibility.
• For safer releases, canary deployments can be introduced to gradually roll out changes and reduce risk.