Smart Feedback Without the Spam: A Three-Layer Defense Strategy

Building a Spam-Resistant Feedback System: Lessons from the Real World

The borisovai-site project needed something every modern developer blog desperately wants: meaningful feedback without drowning in bot comments. The challenge was clear—implement a feedback system that lets readers report issues, mark helpful content, and share insights, all while keeping spam at bay. No signup required, but no open door to chaos either.

The first decision was architectural. Rather than reinventing the wheel with a custom registration system, I chose a multi-layered defense approach. The system would offer three feedback types: bug reports, feature requests, and “helpful” votes. For sensitive operations like bug reports, OAuth authentication through NextAuth.js would be required, creating a natural barrier without friction for legitimate users.

The real puzzle was handling spam and rate limiting. I sketched out three strategies: pure reCAPTCHA, pattern-based detection, and a hybrid approach. The hybrid won. Here’s why: reCAPTCHA alone feels heavy-handed for a simple “mark as helpful” action. Pattern-based detection using regex against common spam markers catches obvious abuse cheaply. But the real protection came from rate limiting—one feedback per IP address per 24 hours, tracked either through Redis or an in-memory store depending on deployment scale.

The implementation stack reflected modern web practices. React 19 with TypeScript provided type safety, Tailwind v4 handled styling efficiently, and Framer Motion added subtle animations that made the interface feel responsive without bloat. The backend connected to Strapi, where I added a new feedback collection with fields tracking the page URL, feedback type, user authentication status, IP address, and a timestamp. The API endpoint itself became a gatekeeper—checking rate limits before creating records, validating input against spam patterns, and returning helpful error messages like “You already left feedback on this page” or “Too many feedbacks from your IP. Try again later.”

One unexpectedly thorny detail: designing the UI for the feedback count. Should we show “23 people found this helpful” or just a percentage? The data model needed to support both, but the psychological impact differs significantly. I opted for showing the count when it exceeded a threshold—small numbers feel insignificant, but once you hit thirty or more, social proof kicks in.

Error handling demanded attention too. Network failures got retry buttons, server errors pointed toward support, and validation errors explained exactly what went wrong. The mobile experience compressed the floating button interface into a minimal footprint while keeping all functionality accessible.

The Tech Insight

Most developers overlook that rate limiting isn’t just about preventing abuse—it’s about conversation design. When someone can only leave one feedback per day, they tend to make it count. They think before commenting. The constraint paradoxically improves feedback quality by making it scarce.

What’s next? The foundation is solid, but integrating an ML-based spam detector from Hugging Face would add a sophistication layer that adapts to evolving attack patterns. For now, the system ships with pattern detection and OAuth—practical, maintainable, and battle-tested by similar implementations across the web.

Why is Linux safe? Hackers peek through Windows only.