Note. This page stays high level on purpose. It explains how things are designed and guarded, not the exact knobs someone could misuse.

What the site is for: rockingnitesh.com is my professional home on the web. It shows work and credentials, takes inbound messages, hands out résumé-style downloads, and gives me a small, invite-only area to keep things updated. The tech footprint stays modest on purpose.

Who uses it

Most traffic is anonymous. A handful of signed-in sessions exist for upkeep. Publicly, you get:

• Content & narrative: the usual “about me” story: background, focus, how I like to work.
• Projects & résumé: proof of delivery you can read without an account.
• Contact: one form, validated on the server, with basic abuse resistance.
• Downloads: PDFs and similar files, usually through short-lived links instead of wide-open buckets.
• Operator tools: a thin slice for me to maintain content and files. Invite-only, explicit privilege, and auditable when it matters.

Core pattern

Nothing exotic here, just a pattern that holds up on real teams:

• Edge delivery: pages ship from managed hosting near users. Only non-secret config is baked into the client.
• Identity: operators use a hosted IdP. Tokens are short-lived. Authorization is never “hide the URL and hope.”
• API layer: one HTTP façade in front of backend work. Policies (who’s calling, from where) run before business logic.
• Serverless compute: small units of logic, each with tight permissions so a bug in one place doesn’t own the whole estate.
• Data: structured rows in a managed database. Binaries in private object storage. Apps mediate access; browsers don’t reach straight into the source of truth.
• Infrastructure as code: environments are described in repo, reviewed like code, and rolled forward deliberately.

Data design

Shape drives where data lives. Structured entities and light telemetry sit in a managed store that fits query patterns and consistency needs. PDFs and similar files sit in private object storage. Access is capability-based and time-bounded when files leave the backend.

Public pages talk to stable APIs. Presentation and persistence stay loosely coupled. Clients never get direct, standing access to the authoritative stores.

Observability

I care about operability, but I keep it proportional. Every workload logs somewhere central. There are baseline metrics and alerts on health. Tracing stays optional until latency or cross-service behavior actually hurts.

When operators change state or touch sensitive artifacts, that should be visible for audit. You get accountability without publishing internal runbooks on the public web.

Resilience

Public reading paths stay boring on purpose. That’s a feature. If an optional integration fails, the site degrades instead of falling over. Retries and async handling show up where third parties are flaky.

Backups and recovery match how painful loss would be. Structured data gets provider-grade durability. File history can be recovered when policy says so, without paying enterprise storage prices for a personal site.

Delivery & security

Changes go through automated checks. Infra deploys use short-lived federation instead of long-lived CI keys. Secrets and per-environment config never live in Git.

Privileged calls always authenticate at the perimeter. You can add more hardening as traffic and risk grow. Write-ups like this one are for hiring managers and peers, not a how-to for breaking in.

So: call it a reference architecture. It’s right-sized for today, but it follows the same habits I use on bigger programs: clear boundaries, sensible controls, and room to grow without ripping everything up.