Ayomide Omojola

EventBook is a production-grade event booking platform deployed on Amazon EKS using a containerized frontend, backend API, and PostgreSQL database. The application is deployed inside an Amazon EKS cluster with three worker nodes. The frontend and backend each run two replicas to provide application availability and allow rolling updates without taking the application offline. Kubernetes Services provide internal service discovery, while NGINX Ingress provides the public entry point to the application. The application is exposed through the domain https://www.eventbook.name.ng. HTTPS is enabled using cert-manager and a Let's Encrypt ClusterIssuer. HTTP traffic is redirected to HTTPS. The frontend is deployed as a hardened container running as a non-root user with dropped Linux capabilities, disabled privilege escalation, and the RuntimeDefault seccomp profile. The backend uses the same security-hardening principles. Kubernetes resource requests and limits are configured for the application workloads to provide predictable resource allocation. The PostgreSQL database runs inside Kubernetes and uses a PersistentVolumeClaim backed by Amazon EBS through the AWS EBS CSI driver. This provides persistent storage independent of the lifecycle of the PostgreSQL pod. PostgreSQL was tested by deleting its pod and verifying that Kubernetes recreated the pod while retaining the database storage. The Kubernetes configuration also includes readiness and liveness probes. Readiness probes prevent traffic from being sent to unhealthy application pods, while liveness probes allow Kubernetes to restart containers that become unhealthy. PodDisruptionBudgets are configured for the frontend and backend to improve availability during voluntary disruptions. RollingUpdate strategies are configured to update workloads without requiring additional cluster capacity. The deployment strategy uses maxUnavailable: 1 and maxSurge: 0 because the EKS node group has a defined pod-capacity limit. NetworkPolicies are included to define the intended communication boundaries between the application components. Sensitive database and application credentials are stored in Kubernetes Secrets and the actual secret files are excluded from version control. CI/CD is implemented using GitHub Actions. The pipeline builds the frontend and backend containers, performs application and infrastructure validation, runs security scanning with Trivy, pushes successful images to Amazon ECR, authenticates to AWS using GitHub OIDC, and deploys the new images to Amazon EKS. Kubernetes rollout status checks are performed after deployment to verify successful updates. Monitoring is implemented using the kube-prometheus-stack, including Prometheus, Grafana, Alertmanager, kube-state-metrics, and Node Exporter. Grafana dashboards monitor Kubernetes workloads, CPU and memory usage, PostgreSQL availability, and frontend/backend replica availability. Application-specific alerts are configured for backend downtime, frontend downtime, PostgreSQL downtime, and high CPU usage. The architecture follows a least-privilege approach. GitHub Actions uses a dedicated IAM role through GitHub OIDC rather than storing long-lived AWS credentials in GitHub. Kubernetes RBAC restricts the GitHub Actions deployment identity to the required deployment operations within the EventBook namespace. The disaster-recovery approach is based primarily on persistent database storage and Kubernetes self-healing. Kubernetes automatically recreates failed application and database pods, while PostgreSQL data is stored on an EBS-backed persistent volume. The architecture can also be restored from the version-controlled Kubernetes manifests and Terraform infrastructure configuration. The project demonstrates containerization, Infrastructure as Code, Kubernetes orchestration, persistent storage, secure application deployment, HTTPS, observability, automated CI/CD, IAM/RBAC, rolling deployments, and production-oriented operational practices on AWS.