Member Avatar for Prateek_2

I am building a url shortner application in php and mysql and
i am using the follwing logic to create short urls, pls tell me how is it

First i fetch the last id from the database using

select max(id) from urls

then suppose if it returns 100 then i convert it into base62 number using this function
suppose it returns x31 then short url will be http://somedomain.com/x31

My question is that is this logic works even when large number of people accessing site at the same time or there will be clash in max(id)

  • 3 Contributors
  • 2 Replies
  • 262 Views
  • 1 Month Discussion Span
  • Latest Post Latest Post by Yorkiebar14

Dani AI

Generated

— the short answer: reading the current maximum and then generating the code from that value is not safe under concurrent load. Two requests can read the same maximum before either inserts, producing identical short codes. As noted, locking or serializable transactions can prevent that, but those approaches are heavier and hurt concurrency.

A simple, robust pattern is to let the DB produce a unique id and derive the short code from that id. Typical flow:

INSERT INTO urls (long_url, created_at) VALUES ('http://example.com', NOW());
SELECT LAST_INSERT_ID();

Then base62-encode the returned id (or use the PDO/mysqli equivalent like $pdo->lastInsertId() / mysqli_insert_id() in PHP). Optionally store the encoded string, or compute it on demand and decode it on redirect (decode → id → SELECT by id). This avoids the race window entirely.

's “random ticket” idea is valid for avoiding sequential codes. If using random tokens, enforce a UNIQUE index on the short-code column and handle duplicates by retrying on duplicate-key errors. For very high scale, consider an atomic counter (Redis INCR), distributed ID generators (Snowflake-style), or an ID-obfuscation library (e.g., hashids) so sequential IDs aren’t obvious.

Practical notes: add a UNIQUE constraint on the short-code, test the insert/get-id flow under concurrent load, and implement a short retry loop for duplicate-key errors. Avoid the read-then-write of a max value — either use the DB’s auto-increment/last-insert-id, an atomic counter, or a properly guarded random-token workflow for safe, collision-free short URLs.

Recommended Answers

All 2 Replies

Member Avatar for hericles

Without knowing more about the queries users will be placing against the database it is hard to be sure but making sure all inputting transactions are wrapped in transactions should stop most conflicts.
Any solution that involves locking the required columns or tables during queries should mean max(id) always returns the correct url.

Member Avatar for Yorkiebar14

Your logic is mostly right. However, whenever I make projects like these, I tend to add an additional feature/column on to my tables which hold a randomly generated string (or, 'ticket') which I then use to reference from $_GET to MySQL(i) tables.
If you're going to use tickets always ensure that you're generating an unused ticket before you insert it.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.