4 ms·

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 p

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."

kevmo314 2y ago
Insta-hire to the candidate that realizes the number of requests is so small that a plain-text file would suffice.
- paulmd 2y ago
  SQLite, sure, but I don’t want a coworker who chooses the hand-crafted full-scan on artisanal csv libraries or w/e
  - jzwinck 2y ago
    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.
    - Mo3 2y ago
      And how would you invalidate the generated codes after 5 days? And is this even scalable to more than one Postzegelcode in circulation?
    - paulmd 2y ago
      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)?
    - eternityforest 2y ago
      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.
      - paulmd 2y ago
        hey mods hire this one
- deleted 2y ago
  [deleted]
- OrderlyTiamat 2y ago
  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.
  - kazinator 2y ago
    If they expire in 5 days, that's 1/6 of a million.
  - pcthrowaway 2y ago
    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.

kevmo314 2y ago

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

paulmd 2y ago
SQLite, sure, but I don’t want a coworker who chooses the hand-crafted full-scan on artisanal csv libraries or w/e
- jzwinck 2y ago
  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.
  - Mo3 2y ago
    And how would you invalidate the generated codes after 5 days? And is this even scalable to more than one Postzegelcode in circulation?
  - paulmd 2y ago
    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)?
  - eternityforest 2y ago
    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.
    - paulmd 2y ago
      hey mods hire this one
deleted 2y ago
[deleted]
OrderlyTiamat 2y ago
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.
- kazinator 2y ago
  If they expire in 5 days, that's 1/6 of a million.
- pcthrowaway 2y ago
  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.