Mar 26 • Notes 📝
BACKEND PROJECT
#Backend_Learning
Today’s progress → On my working project WaitLess
→ From calling a ticket → to serving, holding, completing, and securely cancelling it.
#The_Bug_Fix
→first I thought it was some concurrency or database locking issue but it was something much simpler.
Problem:
→I had changed ticketCode to an integer in Prisma schema, but in PostgreSQL it was still stored as text because the migration didn’t apply properly due to existing data.
→so the database was comparing values like strings, not numbers.
→That means instead of 10 > 9, it was doing string comparison and treating "9" > "10".
→ Because of this, my auto-increment logic started breaking after some point.
→So the issue was not concurrency, it was wrong ordering.
→ Fix was simple:i forced a clean migration reset and made sure ticketCode is actually stored as INT in database.
After that everything worked fine.
Ran multiple stress tests , no crashed occurs and get an expected output.
#State_Machine_Engine
→ Built the strict physical pipeline: CALLED → SERVING → COMPLETED.
→ serveCurrentToken: Checks if the room is empty. If yes, updates state to SERVING and starts the servedAt stopwatch.
→ completeToken: Finds the active appointment, marks as COMPLETED, and stops the clock with completedAt.
→ Enforced the rule: Only ONE user can be SERVING at a single time.
#Edge_Cases
→ Real-world queues are chaotic. People miss their turn or get paused.
→ holdSpecificToken: Moves a user into a PRIORITY bucket.
→ Fixed the time metrics: If they were actively SERVING, we wipe their servedAt time so the break doesn't interfere with the average service time.
→ serveSpecificToken: Squeezes a PRIORITY user back in, bypassing the normal line, but strictly verifying the room is empty first.
#Multi_Actor_Authorization
→ Implemented cancelToken: Who has the right to delete a ticket?
→ Used pure relational database physics to verify permissions before touching state.
→ Actor 1 (Customer): Can only cancel their own ticket (userId match).
→ Actor 2 (Business Owner): Automatically authorized via table relation.
→ Actor 3 (Staff): Looked up directly in the queue_manager junction table.
→ Result: Staff at Queue A cannot cancel a ticket at Queue B.
#We_Can_Say_That
→ A reliable backend is a strict state machine.
→ You have to physically guard endpoints against impossible states (like two people serving at once).
→ Database-level authorization is our strongest shield against cross-tenant data leaks.
#BackendEngineering #PostgreSQL #NodeJS #StateMachines #Prisma #BuildInPublic #SaaS
2
0 comments
BACKEND PROJECT
powered by
skool.com/make-1k-5k-in-30-days-8449
Media Valley School is the fastest way to hit $1K/month with freelancing or agency work. Guaranteed.
Land your first $1K month in 30 days
Suggested communities
Powered by