• Rust microservice design
• API design & certificate lifecycle flows
• PostgreSQL schema & indexing strategy
• Kubernetes components
• Container image design & security

• How mTLS works in microservices
• Certificate rotation
• HSM/KMS for key storage
• Certificate issuance workflow (CSR → signing → storage)

• API consumption patterns
• SSR vs CSR tradeoffs
• Secure cookie/session/token management

• Logging, metrics, tracing
• Kubernetes probes
• Rust performance tuning

1. Issue X.509 certificates (Dummy CA)
2. Store certificate metadata in PostgreSQL
3. Retrieve certificate metadata by ID
4. List certificates with pagination (keyset pagination)
5. Parse PEM files and auto-register certificate metadata
6. Expose secure API for Next.js frontend
7. Monitor certificate expiration (expiring within 30 days)
8. Provide audit logs for all certificate operations

📊 Diagram: System architecture (Excalidraw)

📊 Diagram: Kubernetes Architecture

Async Runtime: Tokio

Library Choices:

Architecture Pattern: Hexagonal Architecture (Ports & Adapters)

API Boundaries:

Each layer communicates only through defined traits. Outbound adapters (DB, CA) can be swapped without changing business logic. e.g. Replace DummyCaService with VaultCaService in production.

OpenAPI / Swagger UI:

🚧 Not implemented in this assessment. In production, would use utoipa crate to auto-generate OpenAPI documentation with Swagger UI at /swagger-ui.

Endpoints:

📊 Diagram: Certificate Lifecycle Flow (Excalidraw)

📊 Diagram: ERD (Excalidraw)

Indexing Strategy:

🚧 Indexes are documented here but not added to the migration files in this assessment. In production, these indexes would be added via a separate migration.

Key Design Decisions:

Audit logs are append-only and time-series in nature — NoSQL or dedicated log storage is often a better fit than relational DB in production.

Recommended production approach:

cert-service → Kafka → Elasticsearch (audit logs + search)
→ PostgreSQL (certificate metadata only)

In this assessment, audit logs are documented but not implemented. In production, Option A would be preferred for strict compliance, Option B for better performance.

cert-service Namespace
  ├── Deployment (2 replicas)
  │     ├── Pod 1 (cert-service container)
  │     └── Pod 2 (cert-service container)
  ├── Service (ClusterIP)
  ├── ConfigMap
  ├── Secret
  └── HPA

nextjs Namespace
  ├── Deployment (2 replicas)
  │     ├── Pod 1 (nextjs container)
  │     └── Pod 2 (nextjs container)
  ├── Service (ClusterIP)
  └── ConfigMap

Ingress (TLS termination)
  ├── api.cert.com → cert-service
  └── app.cert.com → nextjs

External
  └── AWS RDS (PostgreSQL)

Multi-stage build:

Why this works well:

• Dependency compilation is cached separately from application source — faster CI/CD builds
• Runtime image does not include the Rust toolchain — smaller image, reduced attack surface
• cargo-chef improves layer caching when dependencies change less often than source files
• Same image can run locally, in CI, and in production

Security considerations:

In production, add image vulnerability scanning in CI/CD pipeline.

Regular TLS vs mTLS:

In Kubernetes with Istio:

• App code communicates over plain HTTP internally
• Istio sidecar intercepts and wraps traffic with mTLS
• No application code changes required

Implementation Options:

I choose Option B (Istio) for production.

📊 Diagram: Certificate Rotation Flow (Excalidraw)

• cert-manager monitors expiration (1/3 lifespan remaining)
• Generates new key pair
• Requests new certificate from Vault PKI
• Stores in Kubernetes Secret
• Istio injects new certificate (zero downtime)
• Revokes old certificate

Rotation generates a completely new key pair — not a renewal of the existing key.

Private Keys must never be stored in plaintext or in a database. In this assessment: local files. In production: AWS KMS or HashiCorp Vault.

**How to integrate HSM/KMS for key storage: **

cert-manager
↓ Generates CSR
↓ Sends to Vault PKI
Vault PKI
↓ Uses AWS KMS as signing backend
↓ Private Key never leaves KMS boundary
↓ Returns signed certificate
cert-manager
↓ Stores certificate in Kubernetes Secret
↓ Istio injects into pods

cert-manager handles the interaction with Vault PKI, which uses AWS KMS as its signing backend. cert-manager requires a ClusterIssuer configuration pointing to Vault PKI.

In This Assessment (Dummy CA):

Client
↓ POST /certificates (JSON or PEM)
cert-service
↓ Parse & validate
↓ Dummy CA (rcgen) → generate X.509 certificate
↓ Store metadata in PostgreSQL
↓ Return certificate (PEM) + metadata

In Production (Real PKI):

Scenario A — Manual (User/External App Request)

Client (User/Server)
↓ Generate key pair INSIDE KMS/HSM & Create CSR
↓ POST /certificates (CSR)
cert-service
↓ Send CSR to HashiCorp Vault PKI
↓ Vault signs the certificate
↓ Store metadata in PostgreSQL & Return signed certificate

Scenario B — Automated (Internal Mesh Infrastructure)

cert-manager
↓ Generate key pair locally inside K8s & Create CSR
↓ Submit CSR to Vault PKI (via ClusterIssuer)
Vault PKI
↓ Sign certificate & Return to cert-manager
cert-manager
↓ Store in Kubernetes Secret
↓ Istio Envoy hot-reloads it (Zero Downtime)

SSR + SWR Hybrid Pattern:

Browser
↓ Request /inventory
Next.js Server
↓ fetch https://cert-service/certificates (SSR)
↓ Render HTML with initial data
↓ Return complete HTML to browser
Browser
↓ Hydration (React attaches to HTML)
↓ SWR activates → fetch /api/certificates (API Route proxy)
↓ Background revalidation

Why this pattern:

• SSR → fast initial load, SEO friendly
• SWR → keeps data fresh without full page reload
• API Route proxy → avoids self-signed cert issues in browser

In This Assessment:

• No authentication implemented
• Service-to-service authentication handled by mTLS (Istio)

In Production:

Why HttpOnly cookies over localStorage:

• localStorage is accessible via JavaScript → vulnerable to XSS
• HttpOnly cookies cannot be read by JavaScript → XSS safe
• Add SameSite=Strict for CSRF protection
• Add Secure flag for HTTPS-only transmission

JWT Flow in Production:

Login
↓ Issue Access Token (15min) + Refresh Token (30days)
↓ Store both in HttpOnly cookies
Access Token expires
↓ POST /auth/refresh (Refresh Token)
↓ Verify Refresh Token in DB
↓ Issue new Access Token
Logout
↓ Delete Refresh Token from DB (immediate revocation)

Internal service-to-service communication is secured by mTLS via Istio. JWT tokens are only needed for human users accessing the Next.js frontend.

Logging (In This Assessment):

• Structured logging with tracing crate
• Log levels: info (app), debug (tower_http), warn (sqlx)
• Every request tagged with x-request-id for correlation

Request ID Correlation:

INFO request{method=POST uri=/certificates request_id=019e2d0b-...}: started
INFO request{method=POST uri=/certificates request_id=019e2d0b-...}: finished latency=56ms status=201

Metrics (In Production):

• Prometheus scrapes /metrics endpoint
• Grafana dashboards + alerting

Tracing (In Production):

• OpenTelemetry + Jaeger for distributed tracing
• Trace propagated across Next.js → cert-service → PostgreSQL
• Answers: which service is slow? where did the request fail?

Production Observability Stack Options:

Start with Datadog for speed. Migrate to Grafana Stack (Loki + Tempo + Prometheus) as scale grows.

Implemented in This Assessment: