RELAY

Real-Time Collaborative Kanban Board for Teams

A MERN-stack, [Link] powered project & task management tool with live
presence, conflict-safe concurrent editing, and real-time sync — built as a
resume/interview project.

PROJECT MATURITY SCORE

Prototype (as originally built): 4 / 10

Fully Implemented (per this spec): 7.5 - 8 / 10

Prepared as a complete build & interview reference document

Table of Contents
● 1. What Relay Is (Plain-English Overview)
● 2. The Problem It Solves (User Perspective)
● 3. Current State: What Was Originally Built (Prototype)
● 4. Full Feature List (Target / Real Version)
● 5. Complete Technology Stack
● 6. System Architecture
● 7. Database Schema Design
● 8. Real-Time Event Flow ([Link])
● 9. The Hard Technical Problem: Conflict Resolution
● 10. Reconnect & Resync Logic
● 11. Step-by-Step Build Order
● 12. Example User Walkthrough
● 13. Honest Scoring & Resume Positioning
● 14. Likely Interview Questions & How to Answer Them
1. What Relay Is
Relay is a real-time collaborative Kanban (task board) application, similar in spirit to Trello or Linear, built
for small teams — classmates working on a hackathon, a college project group, or a study group
preparing for placements. Multiple people view and edit the same board at the same time, and every
change (moving a card, adding a comment, joining the board) appears instantly on everyone else's
screen without refreshing.

The name and the original file describe it as a 'frontend-only showcase prototype' — meaning the version
it started as only simulates real-time behavior using local component state and timers. This document
describes both that starting point and the complete, real version worth building for a resume/interview.

2. The Problem It Solves (User Perspective)

Student teams currently coordinate using a scattered mix of WhatsApp groups, notes apps, and verbal
check-ins. This causes real, everyday problems:

● No single source of truth for who is doing what task

● Two people accidentally work on the same task
● Work gets lost or overwritten when two people edit the same thing
● No visibility into who is currently online / active
● No history of what changed and when
What using Relay feels like: You open a shared board with columns To Do / In Progress / Done. You
see your teammates' avatars appear the instant they open the board. You drag a card into 'In Progress'
and your teammate sees it move on their screen immediately. You leave a comment on a card and they
see it pop up live. If you and a teammate somehow edit the same card at once, Relay flags the conflict
instead of silently losing someone's change. If your wifi drops, the app quietly catches you back up once
you reconnect.

3. Current State: What Was Originally Built (Prototype)

The original file ([Link]) is a single-file React component — frontend only, no backend, no database,
no real network calls. Every 'real-time' feature is simulated:

Feature shown in UI How it actually works right now

Live cursors of teammates setInterval + [Link]() moving dots — nobody is really there

Presence (who's online) A hardcoded array in useState, not driven by real connections

Drag-and-drop card movement Updates local component state only; nothing is saved anywhere

Disconnect / reconnect simulation A button that toggles a boolean and shows a banner

Conflict warning A fake toast triggered manually via a demo button

AI Summary of comment thread Hardcoded/simulated text — explicitly labeled 'no real model call is made'

Login ("Continue with GitHub") Not wired to any real auth provider
Why this matters: Presenting this version as a finished real-time app in an interview is risky — a
technical interviewer asking 'walk me through how presence sync works' will discover within a couple of
questions that it is entirely simulated.
4. Full Feature List (Target / Real Version)
Core features (must-have)
● User signup/login with real authentication (JWT, hashed passwords)
● Create / join workspaces and boards
● Kanban board with columns: To Do, In Progress, Done (customizable)
● Create, edit, delete cards with title, label, due date, assignee
● Drag-and-drop cards between columns — persisted to database
● Real-time sync: all connected users see moves/edits instantly
● Real presence indicators: who is currently viewing the board
● Comments on cards, live-updating for all viewers
● Activity feed: chronological log of who did what and when

Advanced / differentiating features

● Conflict-safe concurrent editing (optimistic locking with version numbers)
● Reconnect handling: automatic full re-sync after a dropped connection
● Workload view: cards grouped by assignee to see who is overloaded
● Search and filter cards by label, assignee, or due date

Optional stretch features

● Real AI-powered comment thread summarization (actual LLM API call)
● Notifications (in-app or email) for due dates and mentions
● Board-level activity export (CSV/PDF report)

5. Complete Technology Stack

Layer Technology Purpose

Frontend React (Vite), Tailwind CSS, lucide-react UI, styling, icons

Frontend state React hooks (useState/useEffect/useContext) Local UI state management

Real-time client [Link]-client Listen/emit real-time events

Backend runtime [Link] + Express REST API server

Real-time server [Link] (server) Rooms, broadcast events, presence

Database MongoDB + Mongoose Persist users, boards, cards, comments

Auth JWT + bcrypt (or [Link]) Signup/login, password hashing, session tokens

Conflict handling Optimistic locking (version field in schema) Prevent silent overwrite on concurrent edits

Hosting - frontend Vercel or Netlify Deploy React app

Hosting - backend Render or Railway Deploy Node/Express/[Link] server (needs persistent WS su

Database hosting MongoDB Atlas (free tier) Managed cloud MongoDB

Optional AI feature OpenAI/Anthropic API (free-tier / low-cost) Real comment-thread summarization

Version control Git + GitHub Source control, portfolio visibility

6. System Architecture
Three-tier architecture: a React SPA frontend, a Node/Express + [Link] backend, and a MongoDB
Atlas database.

● Client (React): renders board UI, holds an active [Link] connection, sends REST calls for
CRUD, listens for real-time broadcast events
● Server (Express + [Link]): exposes REST endpoints for auth/CRUD; manages [Link]
'rooms' per board; validates and persists writes; broadcasts changes to all other clients in that
board's room
● Database (MongoDB): stores Users, Workspaces, Boards, Cards, Comments, ActivityLog
collections
Request flow example: Client drags a card → sends update request with card ID + new column + current
version number → Server checks version against DB → if match, updates DB and broadcasts
'card_moved' to the board's [Link] room → all other connected clients update their UI instantly.

7. Database Schema Design (MongoDB / Mongoose)

Collection Key Fields

User _id, name, email, passwordHash, avatarColor, createdAt

Workspace _id, name, memberIds[], ownerId

Board _id, workspaceId, name, columns[], createdAt

Card _id, boardId, title, column, position, label, dueDate, assigneeId, version, createdAt, updatedAt

Comment _id, cardId, userId, text, createdAt

ActivityLog _id, boardId, userId, actionType, description, createdAt

Key design point: the 'version' field on Card is what enables safe concurrent editing (see Section 9). The
'position' field on Card enables correct card ordering within a column after drag-and-drop.
8. Real-Time Event Flow ([Link])
Every board has its own [Link] 'room'. Clients join the room for the board they are viewing. Key events:

Event name Direction What it does

join_board Client to Server Client joins the [Link] room for a board

user_joined / user_left Server to Room Broadcast when someone connects/disconnects from a board

card_moved Server to Room Broadcast after a card's column/position is updated in DB

card_updated Server to Room Broadcast after a card's fields (title, label, etc.) are edited

new_comment Server to Room Broadcast after a comment is saved

conflict_detected Server to Client Sent back to a client whose write was rejected due to stale version

resync_request Client to Server (on reconnect)Client asks for the full latest board state

9. The Hard Technical Problem: Conflict Resolution

This is the single most important feature for interview credibility. Without it, Relay is 'just another CRUD
app with sockets.' With it, Relay demonstrates real understanding of concurrency.

The problem
Two users edit or move the same card at nearly the same instant. Without protection, whoever's write
reaches the database last silently overwrites the other person's change with no warning.

The solution: optimistic locking with a version field

● Every Card document has an integer 'version' field, starting at 1
● When a client fetches a card, it also receives the current version number
● When a client submits an update, it sends that version number along with the change
● The server checks: does the submitted version match the current version in the database?
● If yes: apply the update, increment the version to +1, broadcast the change
● If no (someone else updated it first): reject the write, return the current (newer) card state to the
client, and let the client decide whether to reapply their change on top of the latest data
This is exactly the kind of mechanism real production systems (Google Docs, Notion, Trello) use
in simplified form, and it gives you a genuine, defensible answer to 'how do you handle concurrent edits'
in an interview.

10. Reconnect & Resync Logic

When a client's [Link] connection drops (wifi issue, tab backgrounded, etc.) and later reconnects, it
may have missed real-time events (a card moved, a comment was added). Instead of trying to replay
every missed event (complex and error-prone), the simplest robust approach is:

● Detect reconnection ([Link] fires a 'connect' event again after a disconnect)

● On reconnect, the client makes one REST call: fetch the full current state of the board it was viewing
● Replace local state entirely with this fresh data, guaranteeing the client is never stale or inconsistent
11. Step-by-Step Build Order (Recommended for
Vibe-Coding)
1 Step 1: Set up Express + MongoDB, build REST CRUD for boards/cards/comments — no real-time
yet. Deploy this stage first and confirm it fully works.
2 Step 2: Add JWT-based authentication (signup, login, protected routes).
3 Step 3: Add [Link]: broadcast card moves and comments in real time to everyone viewing the
same board.
4 Step 4: Add real presence tracking using actual socket connect/disconnect events (remove any
hardcoded online-user lists).
5 Step 5: Add the version field to the Card schema and implement optimistic locking for conflict-safe
updates.
6 Step 6: Add reconnect handling: full board resync on socket reconnection.
7 Step 7: Polish UI, write the README with an architecture diagram, and deploy frontend + backend +
database with a live public URL.
Budget the most learning time on Step 5 (conflict resolution) — it is the hardest part and the single biggest
differentiator in an interview.

12. Example User Walkthrough

Aisha and Rahul are teammates working on a hackathon project. Both open the same board on separate
laptops.

1 Both connect to the board's [Link] room. Rahul's avatar appears on Aisha's screen the instant he
opens the board (real presence, not a hardcoded list).
2 Rahul drags 'Fix login bug' from To Do into In Progress. His change is saved to MongoDB and
broadcast; Aisha sees the card move on her screen immediately, with no page refresh.
3 Aisha opens the same card and leaves a comment: 'found the bug, it's in the token check.' Rahul
sees the comment appear live.
4 Aisha and Rahul both try to edit the same card's title within moments of each other. The server
detects the version mismatch, rejects the second write, and that user is shown the latest version
instead of silently overwriting the other's change.
5 Aisha's wifi drops for ten seconds. When it reconnects, her client automatically re-fetches the full
board state so she is caught up on anything that changed while she was offline.
Why a team would actually use this instead of WhatsApp + a notes app: one shared source of truth,
no duplicate work, no silently lost edits, and everyone always sees the current state.

13. Honest Scoring & Resume Positioning

● As originally built (frontend-only, simulated real-time): 4 / 10. Good UI/React skills signal, but
risky if presented as a finished real-time product — the illusion breaks under basic technical
questioning.
● Fully implemented per this document (real backend, DB, [Link], optimistic locking,
deployed): 7.5-8 / 10 for a 6-7 LPA target. Demonstrates full-stack ability plus a genuine
concurrency-handling feature, which most resume projects at this level lack.
● To push toward 9-10: get a few real users (your own project team actually using it), add automated
tests for the conflict-resolution logic, and be ready to whiteboard the optimistic-locking flow from
memory.
Resume bullet suggestion: "Built a real-time collaborative Kanban board (MERN + [Link]) with
presence tracking, optimistic-locking based conflict resolution, and automatic state resync on reconnect;
deployed live on Vercel/Render."

14. Likely Interview Questions & How to Answer Them

Q: How do you handle two users editing the same card at once?

A: Explain the version-field optimistic locking approach from Section 9 — reject stale writes, return latest
state.

Q: What happens when a client disconnects and reconnects?

A: Explain the full-resync-on-reconnect strategy from Section 10 rather than trying to replay missed
events.

Q: How is drag-and-drop persisted?

A: Explain optimistic UI update on the client, paired with a server write and version check; describe what
happens on a failed write (rollback / conflict message).

Q: How did you structure your database schema, and why?

A: Walk through the collections in Section 7 — especially why 'position' and 'version' fields exist on Card.

Q: Why MongoDB instead of a SQL database?

A: Flexible schema for evolving card fields, natural fit for document-style nested data (comments could be
embedded or referenced), fast to iterate on during a project-based build.

Q: What would you improve if you had more time?

A: Mention the stretch features from Section 4 - real AI summarization, notifications, and possibly moving
from optimistic locking toward a CRDT-based approach for even finer-grained conflict handling.

End of document — Relay Project Reference