Hacker News Reader

Comment by olooney | Hacker News Reader

This would make a pretty good programming interview question:

"Design a service with two endpoints, one to create a postzegelcode and another to redeem it. A postzegelcode is a nine character, case insensitive alphanumeric code conventionally displayed in all upper case in a 3x3 grid. Postzegelcodes are valid for 5 days after issue and can only be redeemed once. Authentication and payment are out of scope."

View on HN

Insta-hire to the candidate that realizes the number of requests is so small that a plain-text file would suffice.

SQLite, sure, but I don’t want a coworker who chooses the hand-crafted full-scan on artisanal csv libraries or w/e

You don't need a full scan or a giant CSV file. You can do it with a single small file in a single directory. The file contains the state of a pseudo random number generator. On each request, generate a number, save the new PRNG state into a new temp file in a subdirectory, and rename the temp file over top of the original file. If renaming fails, try the whole process a few more times. This allows multiple processes to serve requests concurrently.

Exercise for the reader: avoid re-reading the PRNG state file on retries.

And how would you invalidate the generated codes after 5 days? And is this even scalable to more than one Postzegelcode in circulation?

that sounds like a badly home-rolled uuid4 with extra steps.

How about instead we just generate a uuid4, insert it into a sqlite file or Postgres database, and then the postzegelcode value is threefry(SECRET,uuid)?

Why would you do all that when there's databases engines?

I don't quite understand why programmers love minimalism more than reusing widely trusted and very easy solutions that are known to perform well.

hey mods hire this one

With a million requests per month (~1k a minute average, non uniform distribution ofc), why not just use something like sqlite? I wouldn't want to work with csv files, and development time is the same.

It's a more standard setup, and enables better logging and later changes.

If they expire in 5 days, that's 1/6 of a million.

You don't really need anything relational, so I think sqlite is overkill, and since multiple locations presumably need to write to it, you'd either have to use something like Litestream or write a coordination server to manage the updates from the mail intake locations

I think a Redis instance would be better. Assuming each mail intake device has a unique ID, and ID 0 is intended for un-redeemed postzegelcodes, you could have newly created postzegelcodes SETNX a key with value 0 and a TTL of 5 days, then when mail is being scanned, WATCH the key in a multi transaction, and if the value is 0, SET it to the ID of the intake device, while removing the TTL. The mail can then be rejected at intake if the transaction failed. Upon mail delivery then, you clear the key, which frees it for later re-use.

Reply on news.ycombinator.com