Skip to content

Lab 23: Architecture Review

Field Value
Tier 5 — Capstone
Estimated Time 2 hours
Prerequisites All Tier 1-3 labs
Auto-Grade Yes

Scenario

Your company acquired a startup and inherited their application. The CTO wants an architecture review before integrating it into the main product. The application is deployed on Kubernetes but was designed by a small team that prioritized speed over reliability. The architecture has significant flaws: single points of failure, no security boundaries, tight coupling between services, no caching layer, and the database is the bottleneck for everything.

You need to evaluate the existing architecture, document the flaws, propose improvements, and implement at least five critical fixes. This is not about rewriting the application — it is about making pragmatic improvements that reduce risk and improve reliability with minimal disruption.

Objectives

  • Deploy the flawed architecture in namespace lab-arch-review
  • Document at least 5 architectural flaws in /tmp/lab-arch/review.txt
  • Fix: Add replicas to eliminate single points of failure
  • Fix: Add resource limits and probes to all services
  • Fix: Add a caching layer (Redis) between API and database
  • Fix: Add NetworkPolicies for security boundaries
  • Fix: Create separate services instead of one monolithic endpoint
  • All services Running and healthy after improvements

Setup

./setup.sh

Deploys the flawed architecture in namespace lab-arch-review.

Hints

Hint 1: Identifying single points of failure Any deployment with `replicas: 1` is a SPOF. Also check for services with no readiness probes — they might route traffic to unhealthy pods.
Hint 2: Security boundaries Without NetworkPolicies, every pod can talk to every other pod. Apply default-deny and then add explicit allow rules for required communication paths.
Hint 3: Caching layer Deploy Redis as a caching tier. The API should check Redis before hitting the database. This reduces database load and improves response times.
Hint 4: Service decomposition If one service handles multiple concerns (auth + orders + notifications), consider splitting it into separate deployments with dedicated services.
Hint 5: Architecture review format For each flaw: describe the issue, explain the risk, propose the fix, and estimate the effort (low/medium/high). Prioritize by risk vs effort.

Grading

./grade.sh

Solution

See the solution/ directory for the improved architecture.