Platform engineering, system design and infrastructure shape.
7 items · all topics
When would you scale vertically instead of horizontally?
Go vertical when the bottleneck doesn't split: database buffer cache, cache memory, network bandwidth on one node, a single-threaded lock. Go horizontal when the work partitions cleanly. The real question isn't which is better, it's whether the thing that's saturated can be divided across machines at all.
What happens if an Auto Scaling instance never becomes healthy?
Auto Scaling terminates and replaces an instance that never passes health checks, which is fine once and expensive in a loop. How long you burn depends on the grace period, the check thresholds, and which health check type the group is actually using. The fix is working out why it's unhealthy: usually startup config, a wrong health endpoint, or a grace period shorter than boot time.
Two engineers changed the same Terraform file and Git reports a conflict. How do you resolve it?
Resolve the text conflict, then prove the result is actually correct with terraform validate and a plan. A clean Git merge only means the file parses in a human's head, it says nothing about whether the merged config destroys a database.
Your deployment system needs to know exactly which Git commit is running in production. How do you design that?
Stamp the commit SHA into the artifact at build time and expose it at runtime. Build once per commit, tag and deploy by digest, and serve a /version endpoint, so the answer to "what's live?" comes from the running process itself, not from a pipeline log someone has to go dig up.
Your 5 GB monorepo has code, binaries, Terraform and Helm charts, and clones are slow. What do you do?
Measure what the 5 GB actually is: big blobs, deep history, and a wide tree are three different problems with three different fixes. Work through them in order of cost, artifacts out of Git, binaries into LFS, partial clone and sparse checkout for developers, and treat splitting the repo as the last resort rather than the first idea.
Your organization wants production deployments to be reproducible six months later. How does Git help?
Git pins the source exactly and that's all it pins. Real reproducibility also needs locked dependencies, versioned infrastructure, immutable artifacts, and a stored record linking a deployment to its digest, plus keeping the actual artifact, because rebuilding it later is rarely byte-identical.
Nobody knows which Git branch or tag corresponds to production. How would you fix the release process?
Establish one unbroken chain of identity from commit to running process, then make the pipeline the only way anything reaches production. Start by discovering what's actually deployed today, you can't design a release process around a system you can't describe.