Hope you all are doing well! I just wanted to check in with everyone and ask how was your Ramadan? And how was your Eid? 🤍 ALHAMDULLILAH, my Ramadan went really well. I came for Umrah during Ramadan, and I’m still in Madinah right now. Insha ALLAH, I’ll be back in Karachi in the first week of April. Once I return, we’ll start bringing a lot more energy into our community again, lnsha ALLAH. We’re planning to restart and improve many things, including: - Live sessions - Office hours - More community activities - Better support and interaction for everyone But before that, I’d genuinely love to hear from all of you 💬 Tell me: - How was your Ramadan? - How was your Eid? - What have you been up to lately? - What are you currently working on? - Are you facing any difficulties or challenges right now? - Is there anything you’d like more help or guidance with inside the community? Feel free to share openly I’d love to know how everyone is doing ❤️

#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).

Today’s progress → On my working project WaitLess – implement Queue Lifecycle → From joining a queue → to viewing it → to calling the next person #The_Problem → Multiple users can hit the same endpoint simultaneously → Database does not automatically prevent conflicts → Without proper handling:Duplicate ticket numbers will be assigned,the same user might be called multiple times and it will lead to inconsistent and broken queue state. → challenge: How to maintain correctness under concurrency #Transactions → Used Prisma — $transaction — to wrap critical operations to ensure all steps execute as a single unit and If any step fails the entire operation is rolled back automatically. → Prevents:Half-created records ,Inconsistent data → Guarantees strong data integrity #Row_Level_Locking → Used — SELECT ... FOR UPDATE – to lock specific queue rows . It ensures only one request can modify queue at a time → Other concurrent requests must wait → Prevents race conditions at database level #Problem_Facing the problem i am facing now is that when i create a new queue → when i send request 1 by 1 from postman , its working properly--and after that when i stress test it ------------ faces an error -→ PrismaClientKnownRequestError: Invalid `prisma.token.create()` invocation: Unique constraint failed on the fields: (`"queueId"`, `"ticketCode"`) and then when i send a request again from postman--> then i encounter the above error this time. Similarly when i create another new queue and run a stress test --> the output is perfect as expected - TEST RESULTS --- Request 1: Assigned Ticket #1 Request 2: Assigned Ticket #5 Request 3: Assigned Ticket #2 Request 4: Assigned Ticket #6 Request 5: Assigned Ticket #7 Request 6: Assigned Ticket #4 Request 7: Assigned Ticket #3 Request 8: Assigned Ticket #10 Request 9: Assigned Ticket #8 Request 10: Assigned Ticket #9 after that when i again run a stress test --> faces again the same error PrismaClientKnownRequestError:

Day-5 of learning WebDev #Backend_Engineering Day-5 In the past 3 days, what I have learned and practised: MongoDB & Mongoose →understood MongoDB basics: a NoSQL database that stores data as JSON-like documents. → Learned CRUD operations: Create, Read, Update, Delete. → Realized updates can be full replacement or partial. → Learned filters in updates (_id + userId) to make sure only the intended document is changed. → Practiced using Mongoose to connect, define schemas, and create models (UserModel, TodoModel). → Learned ObjectId usage for uniquely identifying documents and linking todos to users Password Security with bcrypt → Problem: Storing plain-text passwords is dangerous what if the DB leaks, attackers can use them. → Solution: Hash passwords before storing. Hashing is one-way, we can’t reverse it. → New issue: Same passwords give same hash → rainbow table attacks. → Fix: Salt the password before hashing (hash(password + salt)), so identical passwords produce different hashes. → Why bcrypt: 1)Automatically salts passwords 2)Intentionally slow → slows brute-force attacks Zod Validation → Used zod library for request validation. → Validated user signup fields: email format, name, password complexity (uppercase, lowercase, number, special char). → Learned that safeParse gives clear errors when validation fails, improving backend security and reliability. Express.js & Todo App Project → Built a full backend for a todo app using Express.js. → Learned RESTful principles: POST to create, GET to read, PATCH to update partially. → Routes created: Signup: /signup it validates input, hashes password, stores user. Signin: /signin it verifies user credentials, returns JWT token. Create Todo: /todo authenticated route, saves todo linked to userId. Update Todo: /update/:todoId it uses PATCH and $set to change only title.Ensures userId matches, preventing unauthorized changes. Mark Todo as Done: /markasDone/:todoId it uses PATCH and $set to update done boolean

Learning by building projects Day-01 1. The Real-World Problem In local spots like clinics, labs, and barber shops, waiting in line is broken. The Cause: Customers have no idea when their turn is actually coming unless they are physically standing in the room. The Effect: People waste hours sitting in crowded waiting areas just to defend their spot. It is frustrating for the customer and chaotic for the business owner. 2. The Solution I am not building a basic calendar app where you pick a time for next week. I am building a live, real-time queue. A customer takes a digital token on their phone, watches the line move live, and walks in exactly when the admin clicks "Next" for their number. It puts the physical waiting room into their pocket. 3. Why I'm Building this: I have already built basic CRUD apps, but standard tutorials are a trap. They don't teach you how real systems break under pressure. I chose this project to push my backend skills forward by solving three specific engineering problems: Race Conditions: What happens when 50 people click "Get Token" at the exact same millisecond? I am learning how to handle database concurrency so two people don't get Token #5. WebSockets (Real-Time Data): Standard APIs require the user to refresh the page to see updates. I am implementing WebSockets so the queue updates instantly on everyone's phone without reloading. Multi-Tenancy: Instead of hardcoding this for one specific Business, I am architecting the database so multiple different businesses can share the exact same backend securely, without ever seeing each other's data. 4. The Methodology I am not following a step-by-step tutorial. I am employing Question-Driven Development. I am using LLMs strictly as senior architectural mentors. I do not use AI to write my application code or spoon-feed me syntax. I use it to test my database schemas, validate my finite state machines, and expose the edge cases in my system design before I write a single line of code.