boot: ok · v2.0

~/sahil/portfolio

Hello, I’m Sahil

role: backend engineer

I build reliable backend systems, from fault-tolerant Kafka pipelines to real-time sync with CRDTs, and I’m drawn to the infrastructure behind software at scale.

About

I’m a Computer Science student at Ontario Tech University (4.0 GPA, graduating December 2027). I’ve interned at Dayforce and Intact Financial, and this winter I’m joining Wealthsimple’s options and margin trading team.

I’m most interested in the problems behind systems that serve millions of people: distributed storage, reliable transaction processing, low-latency services, and AI infrastructure.

Outside of work, you’ll usually find me playing video games, hanging out with friends, or at the gym. I also used to play Overwatch esports competitively and led a pro team that won over $46K in tournaments.

Skills

languages
C#JavaGoPythonC++TypeScript
frameworks & infra
.NETSpring BootReactDockerKafkaAWS (S3, EC2)
tools
Git / GitHubGitHub ActionsLinux / UNIXSeleniumClaude CodeAI agent workflows
me.jpg Sahil in a minion costume for Halloween: round sparkly goggles, yellow shirt, double peace signs

Experience

Dayforce

Software Engineering Intern

Single Global Person (SGP), two work terms

Current

–present

–

  • C#
  • .NET
  • Kafka
  • React
  • TypeScript
  • Claude Code

Shared audit-trail library

Identified duplicated audit-trail logic across features and replaced it with a shared C#/.NET library for tracking data changes, reducing duplicate code. It has been adopted by multiple teams.

Read the case study

May 2026–present

  • Diagnosed and fixed a high-severity C# race condition in production, replacing unsafe shared dictionary access with thread-safe caching and eliminating the failure condition.
  • Built a full-stack admin tool end-to-end (database schema, C#/.NET APIs, React/TypeScript UI), automating a manual configuration process and reducing a multi-hour task to minutes.
  • Built task-specific AI agent workflows in Claude Code for code research, implementation, testing and review across a large C#/.NET codebase, with manual review before production.

January–September 2025

  • Built Kafka retry handling with exponential backoff, bounded retries and idempotent processing, so failed messages no longer block downstream consumers. Case study
  • Added in-memory caching to C#/.NET APIs across a distributed platform, cutting redundant network calls between services and reducing API latency.
  • Found and fixed CSRF, SSRF and SQL injection vulnerabilities in production C#/.NET services.

Intact Financial

Software Engineering Intern

Content and document management

–

  • Java
  • Spring Boot
  • AWS
  • Selenium
  • Built backend features for a content and document management platform in Java, Spring Boot and AWS, cutting retrieval times by 18%
  • Upgraded legacy services from Java 8 to 25, refactoring deprecated APIs and resolving compatibility issues, reducing memory usage by 20%
  • Built an end-to-end Selenium regression suite for cross-service testing, letting non-developer testers run it in one click and cutting manual QA effort by 40%

Things I’ve built

Two internal projects from Dayforce, described at a high level since the code is proprietary, and one personal project with its code on GitHub.

Shared audit-trail library

Dayforce, internalC#, .NET

One shared library replacing duplicated audit logic across features, now used by multiple teams.

Feature code Audit-trail libraryshared C#/.NET Audit tables Change history Feature code Audit-trail libraryshared C#/.NET Audit tables Change history
Features ask one shared library for change history instead of each reading audit data its own way.
Problem
Several features each had their own logic for reading audit data to show who changed what and when, duplicating the same work in slightly different ways.
Solution
One shared C#/.NET library that replaces that logic and turns audit data into a clear history of changes, so features ask for what changed instead of digging through whole records.
Impact
One consistent way to read change history, less duplicated code, and adoption by multiple teams.

Fault-tolerant Kafka retry handling

Dayforce, internalKafka, C#, .NET

Backoff, bounded retries and idempotent processing, so one bad message never blocks the pipeline.

Kafka topic Consumer Handler Acknowledge Retryexponential backoff Failure state success failure limit reached Kafka topic Consumer Handler Acknowledge Retrybackoff Failurestate success failure
Failed messages are retried with growing delays up to a limit, then set aside in a failure state so they stop blocking everything behind them.
  • Exponential backoff between attempts, so a struggling dependency gets room to recover
  • Bounded retries, so one bad message can't be retried forever
  • Failure-state recovery, so failed messages stop blocking downstream processing
  • Idempotent processing, so a retried message is never applied twice

Distributed collaborative text editor

Personal projectGo, CRDTs, WebSockets, AWS EC2, GitHub Actions

A real-time editor where many people edit the same document at once, and every copy ends up identical.

Concurrent users
10
Simultaneous edits
1,000
p95 latency
2.5 ms
Client editCRDT character Go sync serverordered broadcast Other clientsbuffer and merge Same documenton every client Client editCRDT character Go sync serverordered broadcast Other clientsbuffer and merge Same documenton every client
Edits travel as CRDT characters with permanent IDs, not text positions, so every client places each one in the same spot.
Problem
When people type at the same moment, an edit like “insert at position 12” means different things on different copies, because positions shift. Copies quietly drift apart.
Solution
Every character gets a permanent ID, and a CRDT merges concurrent edits by those IDs. Out-of-order edits wait until what they depend on arrives, re-applying an edit is harmless (idempotent), and late joiners get a snapshot plus any in-flight edits.
Impact
Strong eventual consistency: in load tests with 10 concurrent users making 1,000 simultaneous edits, every client converged, at 2.5 ms p95 latency.
  • Go server using goroutines and channels, routing every edit through one broadcast pipeline so all clients see updates in the same order
  • Load-tested with Claude Code agents driving 10 real WebSocket clients at once and checking that every copy matched
  • GitHub Actions CI/CD running tests with race-condition detection on every push
  • Deployed to AWS EC2 as a Linux systemd service