Friend Request Friend Request

How Friend Requests Actually Work (And Why They're More Complicated Than You Think)

I spent three years building social features for a messaging platform, and the friend request system was always the thing that broke in production even though it looked simple on paper. You'd think accepting and sending connections is just a button click, but there are layers of edge cases that people don't consider until their user base hits fifty thousand. When you send a friend request, the system creates a pending relationship object in your database. This isn't a simple boolean flag - it's a state machine with at least three transitions: pending, accepted, rejected. Most tutorials skip the rejection path because it's boring, but handling rejects properly prevents spam loops and saves your support team from answering the same question four hundred times a day. The actual flow works like this. User A opens the profile of User B and clicks add. The frontend makes a POST request to /api/friends/requests with user_id and target_id. Your backend validates that A isn't already friends with B, that B hasn't blocked A, and that both accounts are active. If all checks pass, you insert a row into the pending_requests table with status 'pending' and a created_at timestamp. User B gets a notification. That's the happy path.

Now the messy part. What happens when User B has privacy settings set to "friends of friends only"? Your system needs to check B's connection graph in real-time. This is where most implementations fail - they query the database once and cache the result, but by the time the cache expires, someone's mutual friend count changed and the request should've been rejected. I learned this the hard way when a user complained they sent sixty requests in one hour and eighty percent bounced silently because the cache was three minutes stale.

Common Pitfalls When Building or Using Friend Systems

Here's what I saw break repeatedly in production. First, the duplicate request problem. User A sends a request to User B. User B accepts. Five seconds later, User A's app still shows "sent" instead of "friends" because the client didn't listen to the websocket update. The fix is idempotent request keys - each client generates a UUID per request and your backend rejects duplicates based on that key, not based on user pairs. Takes twenty minutes to implement and saves hours of support tickets. Second, the circular dependency trap. User A is friends with B, B is friends with C, C is friends with A. When A requests C again (maybe they un-friended accidentally), your graph traversal can hit recursion limits. Use iterative BFS with a visited set and cap it at seven degrees of separation. Anything deeper and you're either computing a recommendation engine or you're about to lock up your server. I had a specific edge case that took me four days to track down. A user reported that their sent requests disappeared after being accepted. Turns out the notification service was deleting pending records on send instead of on accept, so when the acceptance came through the WebSocket, the record was already gone. The friend relationship existed in the database but the UI showed nothing. The workaround was auditing every query that touched the pending table and making sure deletion only happened after you confirmed the acceptance transaction committed. I wrote a migration script that re-linked orphaned relationships and we recovered about two percent of affected users. The rest you just tell them to re-add.

Privacy Settings and How They Break Friend Requests

Most platforms let users toggle who can send requests: everyone, friends only, or nobody. The nobody option sounds straightforward but it causes cascading issues. If User A has "nobody" set and User B sends a request anyway (maybe through a deep link or API call), your system needs to decide: reject silently, queue for later, or notify A that someone tried? I recommend rejecting with a specific error code that the client can translate to "this person isn't accepting requests right now" instead of showing a generic failure. Users tolerate that message better than seeing "error occurred try again". The friends-only setting is trickier. It requires checking whether the requester and recipient share at least one mutual friend. This means a JOIN query on the friendships table, and if your users have large networks, that query gets expensive fast. I optimized this by maintaining a materialized view that updates incrementally rather than computing on every request. The tradeoff is storage but it cuts the query time from two hundred milliseconds to under ten. Worth it when you're handling thousands of requests per second.

What Happens When Friend Requests Get Spammed

This is the problem nobody talks about until it hits you. A bot sends five thousand friend requests in an hour. Your approval queue backs up. Real users can't get their requests seen. Your moderation team drowns. The standard response is rate limiting - maybe ten requests per hour per account - but bots work around this by rotating accounts. A more effective approach is behavioral scoring: accounts that send requests to strangers at high velocity get flagged automatically. I used a simple heuristic: if the ratio of sent requests to existing friends drops below 0.5 and the sending rate exceeds five per minute, pause the account pending manual review. This caught ninety-four percent of bot activity in my experience without blocking legitimate users who were just enthusiastic about making connections. The downside of aggressive filtering is false positives. I had a real user - she was a community organizer building a local network - who sent three hundred requests in a day to event attendees. Her account got flagged and she couldn't undo it herself. We had to manually review and whitelist her. The lesson was adding an appeal path that doesn't require a support ticket. A self-serve verification form where users can link their phone number or email and prove they're human. Takes an afternoon to build and reduces moderation load dramatically.

Deleting and Unfriending: The Forgotten Side of Friend Requests

People focus on adding friends but unfriending causes as many problems. When User A removes User B, does B still see A's private posts? Can B send another request? Most systems leave the old request in limbo - it's neither pending nor rejected, just sitting there. I normalized this by auto-rejecting old pending requests when either party unfriends, which keeps the UI clean and prevents confusion about why a request shows as pending for six months. There's also the blocking question. If User A blocks User B, and B had a pending request to A, that request should disappear immediately. But if A unblocks B later, should the request reappear? The answer is no - that's creep behavior and it violates the principle that consent matters. I learned this from a support case where a user was angry their ex kept seeing old pending requests resurface. The fix was making block status override all relationship states, not just new interactions.

Syncing Friend Lists Across Devices Without Breaking Things

Modern users expect their friend list to be identical on web, iOS, and Android. Achieving this without conflicts is harder than it sounds. User A accepts a request on their phone. Three seconds later, they open the web app and see the old "pending" state because the web client hasn't pulled the latest data yet. The solution is a combination of server-sent events for real-time updates and local cache invalidation. When the server processes an acceptance, it broadcasts the change to all connected clients for that user. The clients mark the relevant cache keys as stale and refetch on next render. This usually cuts sync latency from fifteen seconds to under two, assuming your WebSocket infrastructure is healthy. The edge case is offline mode. What if User B goes offline right after accepting and comes back an hour later? Their pending requests should show as accepted, not pending. I solved this by storing the acceptance timestamp server-side and having the client reconcile differences on reconnect. The algorithm compares the client's local state with the server's authoritative state and applies the minimal set of changes. It's basically conflict-free replicated data type logic applied to friendship graphs. Took me two weeks to get right but it eliminated ninety percent of the sync complaints. One more thing that breaks implementations: timezone handling. User A in Tokyo accepts a request at 11pm. User B in New York sees the notification at 2pm the same day. If your UI displays "just now" without converting to the viewer's timezone, it shows the wrong relative time. Store everything in UTC, convert on read. This is obvious in theory and people still forget it in practice. I've seen notifications say "you have 3 new requests from 14 hours ago" when the requests were actually sent ten minutes apart but across different continents. The fix is a simple timezone offset field on the notification record and client-side conversion using the browser's Intl API.

When Friend Requests Just Don't Work (And What to Do Instead)

Sometimes the friend request model is the wrong tool. For professional networks, a connection request with a note field works better. For closed communities, an invitation system with approval chains is more appropriate. I worked on a platform that tried to force friend requests onto a business-matching feature and it failed because users didn't want to "friend" their clients - they wanted a transactional relationship with clear boundaries. The pivot to a contact system with custom labels solved the problem and increased engagement by forty percent. Another scenario where friend requests break is large groups. A user with ten thousand followers shouldn't be sending individual requests to everyone who follows them. That's a spam trap. Implement a follow/subscribe model for public figures and keep friend requests for one-to-one relationships. The hybrid approach - follows for broad audiences, requests for close connections - handles the scale issue without fragmenting the UX. If your platform is in early stages and you're debating between friend requests and something simpler, start with the simplest option that meets current needs. I've seen teams build elaborate request workflows with custom fields, priority levels, and expiration dates before they had more than five hundred active users. All that complexity sat unused for two years while the core feature - connecting people - was still broken because the UI was confusing. Basic is fine. Add sophistication when you have data showing users actually need it.

The metrics that matter for friend request health are acceptance rate, time to accept, and rejection frequency. If acceptance rates drop below twenty percent, something is wrong - either your matching algorithm is bad, your privacy settings are too aggressive, or users are sending requests to people who don't want them. Track these weekly. The baseline varies by product but anything below ten percent acceptance is a red flag that warrants investigation.

Technical Implementation Details For Developers

For the database schema, you need at minimum: a users table, a friendships table with unique constraints on (user_id, friend_id) to prevent duplicates, and a friend_requests table with status, created_at, accepted_at, and rejected_at fields. The status field should be an enum, not a string - it prevents typos and makes queries faster. Index the friend_requests table on (user_id, status) for the common case of listing pending requests per user. For the API, use RESTful endpoints: POST /requests, GET /requests/pending, POST /requests/{id}/accept, POST /requests/{id}/reject, DELETE /requests/{id}. Each endpoint should return the updated relationship state, not just a success code. Clients need the full object to update their UI without making additional fetches. This reduces round trips and makes the experience feel snappier even on slow networks. Rate limiting should be applied at multiple levels: per user per hour, per IP per minute, and per account per day. The per-IP limit catches bot farms sharing an address. The per-account limit stops compromised accounts from blasting requests. I used token bucket algorithm with a burst capacity of twenty requests and a refill rate of five per minute. This feels generous to real users but stops automated abuse in its tracks. Monitor the rejection rate of your rate limiter - if it's above five percent, you might be too strict and losing legitimate traffic.

Notification delivery deserves its own layer. Don't send email, push, and in-app notifications for every request. That's annoying and your users will disable notifications. Send a single in-app badge count and batch external notifications to once per hour. The exception is high-priority requests - like from verified accounts or people with mutual friends who are also friends with the recipient. These can trigger immediate alerts because they're more likely to be actioned. The heuristic for determining priority is arbitrary but it works: mutual friend count above three plus request within the last hour equals high priority. Finally, log everything related to friend requests for debugging. Record the request creation, every state transition, rate limit decisions, and notification sends. When a user complains their request disappeared, you need to trace the exact path it took through your system. I learned this when a user claimed their request was never received. The logs showed it was sent, accepted, then deleted by a cleanup job that ran every night at 2am. The job had a bug where it deleted accepted requests older than thirty days, which should have been limited to rejected or expired ones. The fix was adding a status check to the cleanup query and it resolved the complaint immediately.