Daniel Shi

I wanted to understand how a database actually stores data, below the SQL. So I'm building the storage layer myself: how pages move between disk and memory, what stays cached, and when writes reach disk.

• Direct I/O. A block-based storage layer opens files with O_DIRECT and uses 4 KB-aligned buffers to bypass the kernel page cache. Thread-safe pread/pwrite calls and lock-free atomic page allocation let many threads do I/O at once.
• Buffer pool manager. An O(1) LRU replacer with pin counting and dirty-page write-back. Pinned frames are never evicted, and modified pages are flushed before their frame is reused.
• Heap files. Bitmapped data pages plus a directory-based heap file in which each directory page tracks 1,024 data pages. Record IDs are stable, bit-packed 64-bit values.

• Why databases manage their own memory instead of trusting the OS page cache.
• How to keep invariants like "pinned pages are never evicted" true under concurrency, and how to test them with GoogleTest.

Portfolios tend to look alike. I wanted one that shows rendering and full-stack skill just by being used, and that still works as a plain, fast, accessible page for anyone who'd rather skip the game.

• A custom render pipeline. The scene renders at 320×180 into a nearest-filtered render target. A fullscreen shader then applies 4×4 Bayer dithering and snaps every pixel to the PICO-8 palette.
• Every model is code. Buildings, props and the player are voxel data built with small helpers (box, roof, compose…), then meshed with face culling and baked shading. Repeated props use InstancedMesh.
• Content as Markdown. Projects and roles are Markdown files validated with Zod at build time. The same parser pre-renders a semantic HTML version for crawlers and the plain view.

• Adding a project or role means adding one Markdown file. Adding a building means one model file and one registry entry.
• Falls back to a plain HTML view without WebGL, and respects prefers-reduced-motion.

REWIND was The Forum's back-to-school party for SFU students at Celebrities Nightclub on September 20, 2026. The venue's ticketing contract meant general sales had to go through TicketWeb, which takes a large cut of every ticket: $30 all-in. Discounted presale and friends-and-family entry were ours to run, at $5 at the door with no fees.

So the club needed one site for the whole campaign: collect a mailing list before the drop, run capped discount guest lists shared privately by promoters, switch to ticket sales the moment the drop happened, and measure which ads produced signups. I was the only person writing code, and I owned the architecture, schema, API, front end and deployment.

• Capacity enforced in one locked database function. Each guest list had 75 spots, and the links went out in group chats, so signups arrived in bursts. Counting and then inserting would let two people both see 74 and push the list to 76, and the club pays for every extra spot at the door. A single PL/pgSQL function locks the list's row (SELECT … FOR UPDATE), then runs the duplicate, signup-window, age, rate-limit and capacity checks and the insert while holding the lock. Different lists never block each other.
• Postgres as the source of truth. Each signup is committed before any third party is called, and every row records whether its Brevo sync succeeded. An outage leaves a row marked for backfill instead of losing a signup. When Brevo rejected a whole contact over a phone-number conflict, the sync retries once without the phone, under a single deadline.
• Built to absorb change. The event was rebranded from "Back 2 School" to the Y2K-themed "Rewind" after the site was built, and the poster art didn't exist yet. Key art is a swappable layer, every string and price lives in one config file, and the palette is a token set, so the rebrand landed as content changes rather than a rewrite.
• Released in the order the campaign needed. Lists are configuration, not code: presale went live first, then general sales, then friends and family as its own pool of 75. That last one was one config entry and one migration, without touching lists already taking real traffic.
• Retargeting and attribution. The Meta Pixel and Conversions API report visits and signups server-side, with UUID event deduplication. That let the club retarget ads at people who visited the site but didn't sign up, and see which ads produced signups.

• Ran the full campaign end to end in production, through to an event that sold 600+ tickets, with 150 discounted guest-list registrations captured in our own database.
• No list ever went over its cap during the signup bursts.
• About 15,000 lines of TypeScript and 850 of SQL, with 397 tests. Some of the tests read the SQL migrations directly and fail if a database function's signature drifts from the code that calls it.
• 91% automated background CRM sync rate and 100% server-side conversion delivery.

• Lay out trade-offs in plain language before anyone commits: what a choice costs, what it buys, and what I expect to happen. "There's no wrong choice, only a misinformed one."
• Spend more time on requirements up front, and book a second meeting after a first attempt, because the real issues only surface once something exists.
• Design the schema to capture more than I think I need. It's easy to ignore a column, and impossible to report on data that was never recorded.

I wanted to understand distributed-systems ideas like atomicity, race conditions and caching in a setting I actually care about: booking sessions on a wall at a bouldering gym. Each wall has a max capacity, and two people must never both get the "last spot", even if their requests arrive at almost the same instant.

• Atomic counters instead of database locks. Checking "is there room?" and then writing "add one more" can race. Redis's INCR is atomic, so incrementing the live headcount and reading the new value happen as one step. If the new count is over capacity, the booking is refused and the count is decremented back.
• Two tiers of data. Live per-slot headcounts and a cached copy of each wall's max capacity live in Redis with self-expiring TTLs. Bookings, gyms and walls persist in a normalised PostgreSQL schema as the source of truth.
• Rollback on write failure. If the Postgres insert fails after Redis lets a booking through, the Redis count is decremented so the spot isn't lost.
• Thin routes, central errors. Services hold the logic; errors are thrown as named codes (WALL_AT_CAPACITY, GYM_NOT_FOUND) and mapped to HTTP statuses in one handler.

• Validated the capacity-limiting and booking logic with targeted Vitest unit tests, mocking Redis and Postgres to cover race conditions, TTL behaviour and rollback on write failure.
• Where this would need more for production: Redis and Postgres can still drift if the app crashes at exactly the wrong moment (an outbox pattern would fix that), and a single Redis node would become Redis Cluster at scale. I wrote up these trade-offs in the repo rather than hiding them.

• Strategy pattern for weapons. A polymorphic weapon system resolves each weapon's behaviour at runtime, which keeps the combat logic simple no matter how many weapons are added.
• Observer pattern between the UI and the game. The game logic publishes changes and the UI listens, keeping a strict separation of concerns.
• Refactoring legacy code. Replaced inheritance with composition, and used the null object pattern to get rid of defensive null checks.

Planning a degree at SFU means digging through prerequisite chains written as free text in course descriptions. It's hard to see which courses unlock which, or what the shortest path to an upper-division course looks like.

• A force-directed graph in D3.js, rendered in Next.js, so you can see prerequisite networks and follow a path by clicking through nodes.
• An automated parsing pipeline using the Gemini API. It turns unstructured prerequisite text into structured JSON, then checks that output before it reaches the graph.

• Won Best Use of SFU Courses API at StormHacks 2025.
• Built and demoed live, with an architecture walkthrough for the judges, inside a 24-hour hackathon.

Planning a trip means checking several sites for the weather, the local population and other basic facts. Travelytics puts them on one dashboard.

• Combines several public APIs and shows the results side by side.
• Built as a team for the CMPT 276 (Software Engineering) final project.

• Deployed on Vercel and live today.

Receipts are messy: crumpled, skewed, and printed in many layouts. We wanted to turn a phone photo into clean, structured fields like the store, line items and totals.

• OpenCV preprocessing (deskewing, thresholding, cropping) before text recognition.
• scikit-learn models classify the recognised text into structured fields.

• Built as the CMPT 310 (Intro to AI) term project; results are summarised in the poster.

"What can I cook with what's in my fridge?" Recipe sites usually start from a dish, not from your ingredients.

• Looks up TheMealDB by ingredient and shows the matching recipes as cards.
• Kept deliberately small so it could ship within the hackathon.

• Shipped at DreamHacks 2025 and deployed on Vercel.