Adding "Custom Slugs" to my SaaS seemed easy... until I realized the edge cases. 🤯

Adding custom links to NanoURL was supposed to be a quick weekend feature: just add a text input, check if the string exists in the database, and save it. Right?

Wrong. Building this feature for scale revealed a massive iceberg of edge cases. Here is how I ended up architecting it to prevent abuse and race conditions:

1. The "Race Condition" Problem
   What happens if two users try to claim nanourl.link/summer-sale at the exact same millisecond?
   Solution: I couldn't rely on a simple existsByShortCode Java check. I had to let PostgreSQL do the heavy lifting with a UNIQUE constraint. If two requests hit the DB at once, the backend catches the DataIntegrityViolationException and translates it into a friendly UI error.

2. The Cooldown & "Self-Lockout" Bug
   To stop bots from sniping deleted dictionary words, I built a 30-day "Cooldown" table. When a link is deleted, it goes into quarantine.
   The Edge Case: I realized that if a user accidentally deleted their own custom link and tried to recreate it, they would lock themselves out for 30 days!
   Solution: I tied the Cooldown record to the workspaceId. Now, the system blocks everyone else, but lets the original owner bypass the cooldown to reclaim their own slug.

3. The "Hybrid Quota" Architecture
   Billing logic is hard. I didn't want free users hoarding dictionary words.
   Solution: I built a hybrid system. Free users are capped by Active Concurrent Links (e.g., max 5 alive at once. Want a 6th? Delete an old one). Paid users are capped by a Monthly Creation Limit. I manage this via a dynamic Key-Value plan_features table, so I can adjust pricing limits in the future without deploying new code.

"Simple" features rarely are. I’m pretty exhausted but incredibly proud of how robust the backend logic turned out.

How do you handle quotas and resource hoarding in your own apps? Do you prefer hard caps or monthly limits?