Kubernetes Migration
Making a working service topology survive an actual deploy.
A service topology that runs locally and a service topology that survives production are different systems. I led the migration of ours (User, Session, Referral, Search, and Chat) onto an Azure Kubernetes cluster, then owned it through to production stability: ingress controllers, external load balancers, readiness probes, and the environment-specific build failures that never reproduce on a developer machine.
I deployed Rocket.Chat as a managed in-cluster service rather than treating real-time communication as an external dependency, which put its configuration, health probes, and database connectivity under the same orchestration model as everything else. One failure model to reason about instead of two. What I'd do differently now is reproduce the environment-specific build differences in CI first, before migrating anything.
Production readiness is a property you design for, not a milestone you reach. Deploy pipeline, health checks, and failure modes are architecture; they just don't show up on the whiteboard.