krishnaSHARMA@backend:~
```text
> Third-year CS student. Backend-leaning, infra-curious, AI-assisted where it counts.
> Currently building : CertiVault — document platform
> Currently learning : Kubernetes, Terraform, distributed systems
> Looking for : Backend / Platform / Infrastructure internship
> Long-term target : Software Engineer
I'm a third-year Computer Science student who spends more time in the backend than the frontend — the auth layer, the queue, the cache, the part of a system that either holds up under load or quietly.
Frontend bugs are visible immediately: something looks wrong, someone notices. Backend bugs are patient. A race condition, a queue that silently drops a job, a token that never expires — these can sit for weeks before they cost someone data or trust. That asymmetry is what pulled me toward backend and infrastructure work in the first place, and it's the lens I build every project through: what happens when this fails, and does the system know it failed?
I care about systems that are:
| 🛡️ Reliable | keep working when a dependency doesn't |
| 👁️ Observable | failure is visible before a user reports it |
| 🧩 Maintainable | the next person (often me, in six months) can reason about it |
| 📈 Scalable | the design doesn't assume load stays where it is today |
Reliability is a design decision, not a bugfix. A system that works in the demo and falls over under concurrent writes isn't reliable, it's untested. I design for the failure case first — what happens if the worker dies mid-job, what happens if the same request arrives twice — and treat the happy path as the easy part.
Queues over blocking calls, whenever the work can wait. If a request doesn't need to be answered synchronously, making the caller wait for it is a cost with no benefit. Offloading it to a queue keeps the API responsive under load, so a slow downstream dependency doesn't become the whole system's problem.
Caching is a trade-off, not a default. Every cache is a promise to keep two copies of the truth in sync. I reach for it when the read cost is real and the staleness window is acceptable — not as a reflex for "making things faster."
Software should fail loud, not silent. A try/catch that swallows an error is a bug wearing a disguise. If something fails, I want a log line, a retry policy, or a dead-letter queue — not a silent no-op that looks like success from the outside.
Observability is what turns "it's slow" into an actionable ticket. Without logs, metrics, or traces, debugging production is guesswork with extra steps. I'd rather spend time instrumenting a system than debugging it blind.
Smart document management and verification platform — authentication, role-based access, hash-based integrity checks on every uploaded file, expiring share links, and background processing for anything that doesn't need to block the request.
Problem. Document-sharing tools tend to get one of two things wrong: they either trust the client too much (anyone with a link has permanent access) or they do too much synchronous work on upload (hashing, notification, thumbnailing), so the API becomes only as fast as its slowest side-effect.
Solution. Separate the request path from the work path. The API's job is to accept the upload, persist it, and enqueue everything else. A pool of background workers does the actual verification and notification work, so a slow hash computation or a flaky email provider never makes a user wait on their upload request.
Engineering decisions:
- Why BullMQ — a job queue with retries, backoff, and visibility into failed jobs, backed by something already in the stack (Redis), rather than standing up a separate broker for a project this size.
- Why Redis — doing two jobs here: backing the BullMQ queue, and caching share-link validation so a hot link doesn't hit MongoDB on every access.
- Why background workers — verification (hashing, integrity checks) and notification (email) are both variable-latency and both tolerant of a few seconds of delay. Neither belongs on the request path.
- Why hashing — every uploaded file gets a SHA-256 checksum computed and stored at upload time. Verification later means recomputing the hash and comparing, not trusting a stored "verified" flag that could be stale or tampered with.
- Maintaining reliability — jobs are idempotent where possible, failed jobs go to a dead-letter queue instead of disappearing, and share links carry their own expiry rather than relying on a cleanup cron to catch them in time.
Lessons learned. The hardest part wasn't any single feature — it was the coordination problems that only show up outside the happy path: two requests hitting the same document at once, a share link that outlives its intended use, a worker that dies mid-job and needs its work picked back up rather than lost.
Node.js Express MongoDB Redis BullMQ Docker JWT Google OAuth Cloudinary
|
Problem. Sharing a file via a link is easy; sharing it safely is the hard part — a link that works for anyone forever isn't sharing, it's a leak with a delay. Solution. JWT-scoped share links with defined access windows, backed by Cloudinary for storage so the app isn't managing raw file I/O itself. Challenge. Getting the scope right: A token needs to prove what it grants access to and until when, without requiring a database round-trip on every access check.. Lesson. Authorization is much easier to get wrong quietly than authentication is — a missing expiry check doesn't throw an error, it just works forever.
|
Problem. Resume feedback tools are either too generic (keyword matching) or require a human reviewer that doesn't scale. Solution. Score a resume against a specific job description using the Claude API, returning structured feedback the UI can render as sections, not a wall of text. Challenge. LLM output isn't naturally structured — getting consistent, parseable JSON back on every call (not just most) meant being explicit about output format and handling the cases where it wasn't. Lesson. Prompting an LLM for a UI-facing feature is an API contract problem as much as a prompting problem — the schema has to hold even when the input resume is messy.
|
|
Problem / Solution. Live forecasts with location search — the most straightforward project on the list. Challenge. Honestly, none technically. This was the first project where I cared about interface quality as much as function, which was its own useful exercise. Lesson. Not every project needs a hard backend problem to be worth building — this one taught me frontend polish instead.
|
Next up in the roadmap after CertiVault ships: a self-hosted secret scanning and rotation intelligence platform — deliberately built on a different stack, with the scan engine (regex + entropy detection) as the core engineering problem. |
| Program | Role | What I actually do |
|---|---|---|
| ECSoC 2026 | Project Admin | Own the project end to end — set scope, define the roadmap, and review every pull request before it merges |
| SSOC 2026 | Mentor | Get first-time contributors to a merged PR — mostly explaining why a change should look a certain way, not just approving or rejecting it |
| GSSoC 2026 | Contributor | Active across issues and PRs on other maintainers' projects |
Running a project rather than just contributing to one changes what you're responsible for. Reviewing a PR isn't just "does this work" — it's judging whether a contributor's approach fits the project's direction, and being able to explain that clearly enough that a first-time contributor learns something instead of just getting a rejection.
Languages
Backend
Data
Infrastructure & Delivery
Testing & Tooling
Self-assessed, updated as I go — not a certification tracker.
Open to backend and infrastructure internships.
