🌐 BrandPulse — Submission Write-Up

✨ Inspiration

BrandPulse was born from a simple but uncomfortable truth: online communities evolve faster than human moderation can keep up with. In environments like Reddit, a single viral post can trigger thousands of emotionally charged responses in minutes, overwhelming volunteer moderators and forcing them into reactive, exhausting triage cycles.

This idea deepened when we studied how brand failures rarely happen without warning. In most cases, early signals of community sentiment collapse already exist, scattered across posts and comments, but they are never surfaced in a unified or timely way.

We set out to build a system that transforms that fragmentation into foresight — turning moderation from a reactive burden into an intelligent, real-time signal layer for community health.

⚙️ What it does

BrandPulse is a real-time AI moderation and sentiment intelligence system built directly on Reddit Devvit, designed to operate under strict platform execution constraints.

It:

Captures posts and comments at creation time using Devvit event triggers
Extracts structured Reddit data despite inconsistent and nested payload formats
Stores events in a Redis-backed caching layer inside Devvit’s constrained server environment
Computes a lightweight risk score (0–100) using sentiment + toxicity heuristics
Applies automated moderation actions (allow, flag, lock, delete) based on thresholds
Logs every moderation decision for traceability and debugging
Exposes secure bridge endpoints for external Python systems to retrieve cached data safely

It functions as both a real-time moderation engine and a community health radar — helping moderators act faster while maintaining full visibility into automated decisions.

🛠️ How we built it

BrandPulse is built inside Reddit Devvit using an event-driven architecture designed specifically around platform constraints rather than traditional backend assumptions.

At its core:

Devvit triggers handle lifecycle events such as on-post-create and on-comment-create
A Hono-based HTTP layer structures internal routing for triggers and bridge endpoints
Redis is used as a lightweight persistence and queueing mechanism inside Devvit’s allowed execution surface
A scoring engine performs real-time moderation classification using simple, explainable heuristics
A bridge API allows external Python systems to retrieve cached data via authenticated requests

🔁 The most important architectural evolution

We originally attempted a direct push architecture:

Devvit → Python API (webhooks / HTTP calls)

This repeatedly failed due to platform-level outbound request restrictions.

We then tried multiple variations:

Devvit → external Python API (blocked / unreliable fetch failures)
Devvit → Redis → Python polling (partial success, but inconsistent assumptions)
Devvit → hybrid push + pull model (race conditions + queue confusion)
Redis list operations misused initially due to misunderstanding of Devvit Redis surface

Eventually, we hit a hard constraint:

External HTTP calls from Devvit are restricted and inconsistent depending on environment state and deployment phase (“pending inclusion” behavior during app lifecycle validation).

💡 Final architecture pivot

We stabilised the system by switching to a strict decoupled model:

Devvit = event capture + caching + moderation decisions
Redis = internal queue + persistence layer
Python = optional downstream consumer (poll-based bridge only)

This removed dependency on unreliable outbound network calls and aligned the system with Devvit’s execution model.

🚧 Challenges we ran into

The biggest challenge was discovering that Devvit is not a traditional backend — it is a restricted event runtime with controlled networking boundaries.

We faced several real production-grade constraints:

1. Outbound network restriction failures

Attempts to push events to Python APIs failed due to:

blocked HTTP requests
SSL hostname mismatch errors
environment-level “not allowed” domain errors
inconsistent deployment state (“pending inclusion” behavior)

This broke the original real-time webhook design entirely.

2. Redis misunderstanding under Devvit constraints

We initially assumed Redis behaved like a full queue system, but:

list operations behaved inconsistently under Devvit server wrappers
some commands were unavailable or surfaced as undefined functions
queue semantics had to be rebuilt using simplified primitives

3. Trigger instability under real Reddit traffic

We encountered:

inconsistent payload shapes across post/comment triggers
nested object variance across event types
missing fields depending on Reddit event source

This required defensive extraction logic instead of strict schemas.

4. Execution safety constraints

We had to ensure:

background tasks never blocked trigger execution
moderation logic could not crash event handlers
all external calls were isolated or removed entirely

This forced a strict fire-and-forget + try/catch isolation model

5. Architectural overcorrection cycles

We iterated through multiple broken mental models:

“Devvit is a server” ❌
“Devvit can push to APIs” ❌
“Redis is a full queue broker here” ⚠️
“Everything should be real-time push” ❌

The final insight was:

Devvit is an event capture layer, not a distributed backend system.

🏆 Accomplishments that we're proud of

Despite platform constraints and repeated architectural failure cycles, we successfully built:

A real-time Reddit event capture system operating inside Devvit constraints
A resilient Redis-backed caching + queue mechanism
A safe bridge layer for external Python consumption
A working moderation engine that survives high-volume event bursts
Explainable risk scoring instead of opaque ML outputs
A hybrid architecture that respects platform boundaries instead of fighting them

Most importantly, we transformed early instability — including blocked network calls, Redis confusion, and trigger failures — into a stable constraint-aware system design.