Skip to content
Download résumé
Open to Summer 2027 internshipsBangalore, India

I build the layer underneath the product.

Shivam MishraSystems & Distributed Backend Engineer

CS undergraduate at DSCE Bangalore working on systems design, distributed systems and microservices. I write C++17 storage engines, Kafka-backed inference pipelines, and I ship upstream fixes to Meshery — a CNCF cloud-native project — by tracing bugs to their actual root cause instead of patching the symptom.

upstream CNCF contributions
6
CGPA / 10.0
8.2
CTF points — top scorer
4,950
Codeforces rating
1240
  • Go
  • C++17
  • Python
  • TypeScript
  • Apache Kafka
  • Kubernetes
  • Docker
  • PostgreSQL
  • FastAPI
  • React
  • Linux
  • Distributed Systems
  • Concurrency
  • Systems Design
01About

I like the parts of software that have no UI.

Most of my time goes into the layer where correctness is non-negotiable: write-ahead logs that survive a crash mid-flush, consumers that keep up when the producer refuses to slow down, locks that let a hundred readers through without letting one writer corrupt the page. I started there because it was the part I could not fake my way through.

That instinct is also how I contribute to open source. On Meshery — a CNCF cloud-native management plane — I have walked a broken UI regression backwards through several merge commits to a single dropped import, verified a missing CLI filter against a backend that already supported it, and pinned a docs rendering bug to the exact Hugo template line responsible. The fix is usually small. Finding out which line actually deserves the fix is the work.

Right now I am looking for internships where the hard problems are infrastructural — storage, streaming, scheduling, developer tooling — and where I get to read a lot of code written by people better than me.

Education

Dayananda Sagar College of Engineering (DSCE)

B.E. in Computer Science and Engineering

Expected July 2028

CGPA 8.2 / 10.0

Coursework focus in AI/ML and DevOps. Primary interest: systems design, distributed systems and microservices.

Spec sheet

Based in
Bangalore, India
Studying
B.E. Computer Science, DSCE
Graduating
July 2028
Focus
Distributed systems · Storage · Microservices
Coursework
AI/ML · DevOps
Open source
Meshery (CNCF)
Seeking
Summer 2027 internships

“The fix is usually small. Finding out which line actually deserves the fix is the work.”

02Capabilities

The toolkit, and what it is for.

Grouped by the problem they solve rather than by logo. Everything listed here has shipped in a project, a contribution or a contest.

01

Languages

What I reach for, and why.

  • GoMeshery server, CLI tooling
  • C / C++17Storage engines, concurrency
  • PythonPipelines, CV, tooling
  • TypeScript / JavaScriptReact UI work
  • JavaOOP, DSA
  • SQLSchema design, query tuning
02

Backend & Data

Services, contracts and the stores behind them.

  • FastAPIAsync ingestion APIs
  • Apache KafkaEvent-driven decoupling
  • PostgreSQLDurable event sink
  • Flask
  • REST API design
  • Microservice architecture
03

Systems & Low-Level

Where the guarantees actually live.

  • LSM-tree internalsMemTable, SSTable, compaction
  • Write-Ahead LoggingCrash-consistent durability
  • Multi-threadingstd::shared_mutex, RW locks
  • Concurrency control
  • Memory & fault modellingBit-flips, stuck-at faults
  • LinuxDaily driver
04

Infra & Tooling

Getting it to run the same way twice.

  • Docker / ComposeHealthchecked multi-service stacks
  • Kubernetes
  • Git & GitHubUpstream OSS workflow
  • Hugo / DocsyDocs site internals
  • Streamlit
05

ML & Vision

Applied, not academic — inference under a latency budget.

  • YOLOv8 (Ultralytics)Headless inference workers
  • PyTorch
  • OpenCV
  • NumPy
06

Foundations

The theory I keep coming back to.

  • Distributed Systems
  • System Design
  • Data Structures & Algorithms
  • Operating Systems concepts
  • DBMS
  • OOP
03Experience

Where I've been shipping.

Open source is my main proving ground: real reviewers, real regressions, real merge conflicts.

Jun 2026 — Present

Meshery

CNCF Cloud Native Project

Open Source Contributor

Remote

meshery/meshery
  • Go
  • React
  • Hugo
  • Docsy
  • CLI
  • E2E testing

Contributing across the full surface of a CNCF project: the Go server, the mesheryctl CLI, the React UI and the Hugo documentation site. My pattern is consistent — reproduce, bisect, root-cause, then fix the cause.

  • 01

    Traced a UI regression — broken Settings tabs and two failing E2E tests — backwards through several merge commits to a single dropped import, then fixed and verified it end to end rather than patching the visible symptom.

  • 02

    Verified through the mesheryctl CLI that component search was missing a --model filter even though the backend already exposed model filtering via ComponentFilter.ModelName; implemented, tested and validated the fix end to end.

  • 03

    Diagnosed a documentation rendering bug — missing page headings on Hugo/Docsy section-index pages — down to the exact template line responsible, and filed a root-caused issue with reproduction steps.

  • 04

    Restructured and shipped documentation changes to match existing project conventions after maintainer review, including an intra-page table of contents for dynamically generated model pages and a shortcode reference guide for docs contributors.

Jun 2026

Deloitte Australia

Forage Virtual Job Simulation

Technology Job Simulation

Remote

  • Python
  • Data modelling
  • Data visualisation
  • Log analysis

Worked through development and coding tasks inside a simulated technology-consulting engagement.

  • 01

    Designed a technical proposal for a client-facing data analytics dashboard, covering data modelling, visualisation strategy and log analysis.

  • 02

    Applied Python for data processing and forensic log analysis against a realistic client brief.

04Selected work

Three systems, built to hold under load.

Each of these started as a guarantee I wanted to be able to make — no dropped frames, no data loss on crash, no hand-waving about bit-flips — and the architecture followed from it.

Distributed AI Video Pipeline

Event-driven inference that does not drop frames when it gets busy.

Architecturedistributed-ai-video-pipeline
distributed-ai-video-pipelineEdge ingestion built on FastAPI publishes sampled frames to an Apache Kafka topic. A consumer group of headless YOLOv8 inference workers reads from the topic and writes detection events to PostgreSQL. The whole stack runs under Docker Compose with healthchecks.Docker Compose · healthcheckedEdge IngestFastAPI · OpenCVvideo sourcesample every 5th frame−80% CPU loadApache Kafkatopic: framesbackpressure absorbed hereYOLOv8 worker 1consumer groupYOLOv8 worker 2consumer groupYOLOv8 worker 3consumer groupscale out by adding consumersPostgreSQLdetection events

Kafka is the load-bearing decision: ingestion never blocks on inference, so a burst becomes queue depth instead of lost frames. Throughput scales by adding consumers to the group.

The problem

A naïve video analytics service couples capture to inference: the camera loop calls the model directly. The moment the GPU falls behind the camera, frames are silently dropped and the detection record becomes a lie. The system needs to absorb bursts without losing evidence.

What I built

  • Architected an event-driven microservice pipeline that decouples edge ingestion from neural-network compute through Kafka, so backpressure lands in a durable log instead of in the capture loop.

  • Implemented smart frame sampling — every 5th frame — cutting CPU load by 80% while keeping detection continuity for the tracked subject.

  • Deployed headless YOLOv8 inference nodes as Kafka consumers, letting throughput scale by adding consumers to the group rather than rewriting the pipeline.

  • Containerised the whole stack with Docker Compose and dependency healthchecks across Zookeeper, Kafka and PostgreSQL so the system comes up in the right order, every time.

  • Persisted detection events to PostgreSQL as the durable sink for downstream querying and replay.

LSM-Tree Storage Engine

A key-value engine built from scratch in C++17 — the architecture behind LevelDB and RocksDB.

Architecturelsm-tree-storage-engine
lsm-tree-storage-engineA write is appended to the Write-Ahead Log on disk and inserted into an in-memory MemTable guarded by a shared_mutex. When the MemTable fills it becomes immutable and is flushed to an L0 SSTable. A background compaction engine merges L0 into L1 and L1 into L2.memorydiskput(k, v)client writeMemTablestd::shared_mutexImmutable MemTableflush queued2 · insertsealed when fullWrite-Ahead Logappend-onlyCompactionbackgroundL0SSTableflushed, unsorted overlapL1SSTablemerged, non-overlappingL2SSTablecompacted1 · append (fsync)3 · flush to L0mergereplay on crash → zero data loss

Acknowledgement happens after the WAL append, not after the flush — durability without paying disk-flush latency on every put. std::shared_mutex lets concurrent readers through while a writer holds exclusive access.

The problem

Reading about LSM-trees teaches you the diagram. It does not teach you what happens when a flush races a read, or what the log has to contain for a crash mid-write to be recoverable. So I built the engine instead of reading about it.

What I built

  • Built a high-performance embedded key-value storage engine from scratch in C++17, implementing the Log-Structured Merge-Tree architecture that underpins LevelDB and RocksDB.

  • Engineered a thread-safe MemTable using std::shared_mutex read-write locks, so concurrent readers proceed in parallel while writers take exclusive access.

  • Implemented Write-Ahead Logging so that a crash between an acknowledged write and the SSTable flush is recoverable — zero data loss on crash.

  • Wrote a background compaction engine performing leveled SSTable merging, keeping read amplification bounded as the dataset grows.

  • Designed the write path so acknowledgement happens after the WAL append, not after the flush — durability without paying disk latency on every put.

Memory Corruption & Hardware Fault Simulator

Making cosmic-ray bit-flips visible, one memory cell at a time.

Role
Co-developed — 3-person team
Year
2026
Architecturememory-fault-simulator
memory-fault-simulatorA Streamlit control panel injects faults into a NumPy-modelled memory array. Transient single-bit upsets appear as isolated flipped cells; permanent stuck-at gate faults appear as a fixed column that never changes value. The corrupted array is rendered back to the panel in real time.Streamlit panelfault injection controlsrate · address · fault typememory array · NumPy bit-plane010101011010101001010101101000100101010110100010address space →Transient bit-flipcosmic-ray single-event upsetStuck-at gate faultpermanent, same addressClean cellLive visualisationcorruption spreadinject

Two fault classes with deliberately different signatures: a transient upset scatters, a stuck-at fault repeats at the same address forever. Seeing them side by side is the whole pedagogical point.

The problem

Fault tolerance is taught as an abstraction: 'bits flip, so we add ECC'. Nobody sees the flip. We built a tool that injects the fault, shows the corruption spread through memory, and makes the hardware–software boundary concrete.

What I built

  • Co-developed a visual simulation tool modelling memory-level hardware faults — cosmic-ray induced bit-flips and stuck-at gate faults — to bridge hardware–software interaction and fault-tolerance concepts.

  • Modelled the memory array with NumPy so fault injection and corruption propagation are computed over the whole address space at once.

  • Built an interactive Streamlit interface for real-time fault injection and live visualisation of memory corruption patterns.

  • Supported multiple fault classes — transient single-bit upsets versus permanent stuck-at-0 / stuck-at-1 gate faults — so their different failure signatures can be compared side by side.

05Achievements & competitions

Results under a clock.

National-level engineering challenges, capture-the-flag competitions and rated contests — the places where the constraint is time and the scoring is public.

3rd

XYTHERA CTF

AWS Student Builder Club, DSCE — Team BlackStar

Scored 4,950 points individually — the highest on the team. We entered outside the top 10 and finished 3rd overall.

  • Capture the Flag
  • Security
  • Team of 4

Semifinal

Flipkart GRiD 8.0

National Engineering Challenge

Cleared Rounds 1 and 2 against a national field and advanced to the Round 3 semifinal.

  • National
  • Engineering Challenge
06Certifications & volunteering

Programmes, communities, and service.

Certifications & programmes

03

Communities & volunteering

04
  • Microsoft Student Ambassador

    Aug 2026 — Present

    Microsoft

    Cloud and DevOps skill-building through Microsoft Learn certification pathways — Azure fundamentals, GitHub workflows and CI/CD automation with GitHub Actions — alongside a global community of student developers.

  • Member

    2026 — Present

    AWS Student Builder Club, DSCE

    Cloud and security community at DSCE; competed for the club at XYTHERA CTF.

  • House Captain

    School leadership

    Delhi Public School, Azad Nagar

    Led inter-house coordination across events, logistics and team selection.

  • Delegate

    School leadership

    Model United Nations

    Represented delegations in committee — research, position papers and live debate.

07Connect

Let's build something that has to stay up.

I'm looking for software engineering and research internships in distributed systems, storage, developer tooling and infrastructure. If that's the kind of work on your team's roadmap, I'd like to hear about it.

smishraa30@gmail.comDownload résuméOpen to Summer 2027 internships