StoryHub

I chose a flattened threaded comment model with inline @mentions instead of an infinitely nested hierarchical structure. The goal was to preserve conversational context without allowing the UI and DOM structure to grow increasingly complex with every level of nesting.

Rather than recursively rendering deeply nested comment trees, replies remain within a flatter discussion structure while @mentions provide explicit context about who a reply is directed toward. This keeps discussions easier to scan and reduces frontend rendering complexity as conversations grow, while still preserving the relationship between participants and their replies.

StoryHub relies heavily on user-generated media such as avatars and post cover images. I wanted to keep these assets outside the application while still using Next.js's Image component for optimized delivery. Since remote image sources need to be explicitly configured, centralizing user media in Supabase Storage gave me a predictable storage layer and a controlled image origin.

I chose private Supabase buckets with signed URLs rather than exposing assets through public URLs. Private buckets keep object access protected, while signed URLs provide temporary, controlled access when an image needs to be rendered. This introduced additional complexity around generating and handling expiring URLs, but provided a reusable access-control model across StoryHub's different media buckets.

Scheduled publishing required StoryHub to periodically trigger a secure server-side endpoint that checks for posts whose scheduled time has been reached and transitions them to published.

I initially considered using Vercel Cron Jobs, but the Hobby plan only supports once-daily cron execution, while StoryHub needed much finer-grained scheduling to publish posts close to their intended time.

Instead of introducing a paid infrastructure dependency for this requirement, I used cron-job.org as an external scheduler to invoke the publishing endpoint at a regular interval with a secret authorization header. The endpoint then performs the database checks and publishes eligible posts.

This kept the publishing logic inside StoryHub while using a lightweight external service only for scheduled triggering, giving the system the scheduling frequency it needed without unnecessarily increasing infrastructure cost.

Real-time notifications were an important part of StoryHub, but the communication pattern was primarily one-way: the server needed to push events to connected clients. I considered WebSockets, but they would introduce a bidirectional communication model that StoryHub's notification system didn't actually require.

I chose Server-Sent Events (SSE) because it works over standard HTTP and integrates naturally with Next.js Route Handlers through streaming responses. This allowed the application to maintain a server-to-client event stream without introducing a separate WebSocket server or additional real-time infrastructure.

The browser's native EventSource API also provides built-in reconnection behavior, reducing the amount of connection-management logic I needed to implement myself.

Although WebSockets are now supported on Vercel through its newer Fluid Compute/WebSocket capabilities, SSE remained the better fit for StoryHub because its notification requirements were unidirectional and didn't justify the additional complexity of a bidirectional protocol.

StoryHub's email notification system needed to handle notification events outside the user's request-response cycle. Instead of processing email generation and delivery synchronously, I designed an asynchronous digest workflow that could collect events, batch them, and process them independently.

Upstash Redis serves as the fast, short-lived data layer for this workflow. Notification events are temporarily stored and aggregated there before being grouped into email digests, while Redis also maintains the state required for email rate limiting. Its fast key-value operations, expiration capabilities, and lightweight counters made it a good fit for this high-frequency, transient data rather than storing it in MongoDB, which remains StoryHub's primary persistent data store.

BullMQ provides the queue and worker layer on top of Redis. Once email processing is triggered, jobs can be queued and handled asynchronously by a worker that batches the relevant notifications into digest emails and sends them through Resend. Moving this work into a background workflow prevents email processing from delaying user-facing requests while also providing structured job handling, including retries and failure management.

This created a clear separation of responsibilities: Redis manages transient digest and rate-limiting state, BullMQ manages asynchronous job processing, and Resend handles email delivery.

After the security audit exposed gaps across authentication, authorization, user input, file uploads, sessions, dependencies, and information exposure, StoryHub's security hardening treated these areas as interconnected parts of the application's security surface.