Asyhari Achmad Ichsan Cerlang Religia

Concrete production snapshot

• Hosting: single VPS (2 vCPU, ~4 GB RAM, ~80 GB SSD), Newark region (US).
• Edge: Cloudflare for DNS/CDN; edge protections are configured at Cloudflare; TLS terminates on-host via Nginx + Let’s Encrypt.
• Runtime: systemd unit runs Gunicorn (threaded workers) behind Nginx on localhost.
• Data: SQLite primary DB with WAL; staging uses a separate service + separate DB file.
• Observability: Nginx + app logs; lightweight in-app counters + admin metrics view; health endpoints for uptime checks.

Scaling triggers (when to change the architecture)

• Higher write concurrency: migrate from SQLite to a managed relational DB.
• Heavy reporting needs: separate reporting storage from transactional storage.
• Availability requirements: move from single-node to redundant deployment with automated failover.

The deployment flow is intentionally boring: changes are reviewed in the dev environment, pushed to GitHub, then pulled on the prod VPS. The service reloads cleanly via systemd (no background Flask, no mystery processes).

Why this is operationally sane

• Change control: one canonical repo; deterministic deploy steps; explicit rollback via known-good commit.
• Reliability: Gunicorn is process-managed; Nginx keeps the edge stable during reloads.
• Auditability: deploys map to commits; operational actions are repeatable and documentable.

Demo workspace (product navigation)

A demo workspace exposes the product surfaces through a tabbed window so stakeholders can click through the experience without needing a full account setup.

The demo workspace uses sanitized, static demo pages and tokens and does not use real user data.

The platform treats user data as sensitive even before formal regulatory requirements exist. The goal is to be “compliance-ready” without adding heavy tooling too early.

Data retention and deletion are defined in the /privacy and /terms pages.

Data	Sensitivity	Controls (current)
Email + username	High (identifier)	Transport encryption (TLS), server-side access checks, least-sharing in UI, no secrets in client code.
Assessment responses + results	High (profile inference)	Stored server-side, computed server-side, protected by account boundaries; logging avoids raw payload dumps.
Work history matched from LinkedIn	High (employment history)	Stored for user value; access constrained to the account; operational handling treated as sensitive.

This section explains the core of CareerMeasure: how raw inputs become ranked career matches, and how the standardized career and labor datasets are ingested and versioned.

Algorithm notes (high level)

• Deterministic scoring: the backend computes the same result for the same inputs, with explicit versioning for scoring changes.
• Server-side computation: match scoring is computed on the server; the frontend only renders what the backend returns.
• Explainable output: results include structured "why" explanations that map to measured signals, not vague claims.

Source attribution and version notes belong on the /credits page. This case study focuses on the implementation and operational posture.

Security controls: translating policy into build decisions

• Access control: admin paths are server-side gated; production access is intentionally limited (currently single-operator).
• Change management: deployments map to commits; rollback is a defined procedure; staging exists for safer testing.
• Logging: operational logs exist at Nginx + app layers; sensitive payloads are treated as restricted.
• Rate limiting: public endpoints are guarded to reduce abuse and operational risk.

Continuity & recovery: current state and hardening plan

• Continuity targets: RTO (Recovery Time Objective) ≤ 4 hours, RPO (Recovery Point Objective) ≤ 24 hours (after automated offsite backups are in place).
• Current DR reality: DR (Disaster Recovery) is a rebuild from repo + restore SQLite file from latest snapshot + service restart.
• Known gap: backups are primarily on-host today (single-node concentration risk).
• Fast improvement (next): automate offsite encrypted backups + define retention + run restore drills on a schedule.

Ops runbook (minimal, repeatable)

• Deploy: pull the release commit, reload service, run smoke checks.
• Rollback: revert to known-good commit and redeploy; verify health and critical flows.
• Backup: take DB snapshots; verify snapshot integrity; retention follows a defined policy.
• Restore drill: run timed restores on a non-production environment with a functional smoke test (target monthly cadence).
• Patching cadence: scheduled OS and dependency patch window with a short checklist and rollback plan.

This section separates “current state” from “next hardening steps” so availability and recovery claims remain evidence-based.

Finance-facing operations are designed so billing-related state changes are traceable and recoverable: checkout and subscription events update access state, and key changes are recorded as database events for later review.

Access updates are driven by verified webhook events. Payout settlement is separate and asynchronous.

Polar acts as Merchant of Record for customer transactions and uses Stripe Connect Express to transfer earnings to the merchant. Payouts are received net of fees and applicable taxes based on configuration.

What this enables

• Entitlement integrity: premium access is derived from server-side subscription state, updated by verified webhook events and recorded for review.
• Traceability: when subscription tier changes, the new state is persisted and the change is recorded as an event.
• Audit support: finance and ops can reconcile “who has access” against recorded billing events.
• Operational safety: webhook handlers validate inbound events before updating user state.

Exception handling (high level)

• Cancellation: access remains active until period end or changes immediately based on the event received.
• Refunds and chargebacks: access can be revoked by subscription state changes and recorded as an audit event.
• Payout timing: settlement timing is independent from entitlement updates and can lag customer events.

Risks are tracked with an owner role and a next action date so mitigations are scheduled, not aspirational.

Risk	Owner	Next action	Target date
Single-node state (DB + backups)	Operations	Automate encrypted offsite backups and run first restore drill	February 2026
Manual deploy gates	Engineering	Add CI for `pytest tests/ -v` and basic dependency scanning	February 2026
Limited alerting	Operations	Add external uptime checks and error alerting for 5xx spikes	March 2026
Privileged admin scope	Security	Enforce MFA, document access review cadence, and audit admin changes	March 2026

Operational improvements follow a Six Sigma-style DMAIC loop (Define → Measure → Analyze → Improve → Control) so changes are prioritized, measurable, and sustained.

Operational KPIs (measured and controlled)

KPI	Target	How it is measured
Availability	Uptime target (tracked monthly)	External uptime check + `/api/health` response monitoring
Latency	P95 page and API response time	App logs (timings) + edge/proxy logs for request duration
Error rate	5xx rate and crash-free sessions	Nginx status codes + application error logs
Backup success	Daily snapshot success rate	Backup job logs + file integrity verification
Restore confidence	Monthly restore drill pass	Documented restore steps with timed execution and a functional smoke test
Change failure rate	Low rate of rollbacks per deploy	Deploy log + commit traceability + post-deploy smoke checks

• Define: scope the problem (e.g., “reduce deploy risk” or “increase restore confidence”).
• Measure: pick measurable signals (latency, error rate, backup success rate, restore drill time).
• Analyze: find root causes (single-node dependencies, manual steps, missing alerts).
• Improve: implement minimal fixes (automation, safer deploy steps, clearer runbooks).
• Control: keep it from regressing (health checks, dashboards, recurring drills, change reviews).

These are intentionally small, readable snippets that demonstrate the engineering posture: health checks, process supervision, reverse proxying, deployments, and rate limiting.

Health check pattern (simplified)

Provides a fast, reliable signal for uptime checks and deploy smoke tests by exercising the app and database path.

@api_bp.route("/health")
	def health_check():
	    db.session.execute(text("SELECT 1"))
	    return jsonify({"status": "ok"})

Gunicorn behind Nginx (sanitized)

Uses a process-managed application server so the service stays stable across reloads and failures.

# systemd-managed gunicorn (conceptual)
	gunicorn -w 2 --threads 2 --worker-class gthread \\
	  --max-requests 1000 --max-requests-jitter 50 \\
	  --timeout 120 -b 127.0.0.1:8005 app:app

Nginx reverse proxy (sanitized)

Keeps the public edge consistent while proxying requests to the app on localhost, and preserves client identity for logs and rate limiting.

location / {
    proxy_pass http://127.0.0.1:8005;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Deploy pull and reload (sanitized)

Makes releases deterministic and auditable by tying deployments to commits, then validates a known-good health endpoint after reload.

git fetch origin main
git reset --hard origin/main
systemctl reload app.service
curl -fsS http://127.0.0.1:8005/api/health

Rate limiting posture (conceptual)

Reduces abuse risk and protects availability by enforcing simple request budgets on public endpoints.

resp = apply_rate_limit("60 per minute")
if resp:
    return resp