4 ms·

They didn’t even know there was an error until the customers came ringing. You always want to know what errors happened before your customers do, logging, alert

They didn’t even know there was an error until the customers came ringing. You always want to know what errors happened before your customers do, logging, alerting, any monitoring at all would have helped them here.

theamk 2y ago
They had 5 days... they knew after the first night
lawgimenez 2y ago
Experience should tell you to always take a hard look at anything UUIDs.
- stouset 2y ago
  Also facepalms here: UUIDs as strings and UUIDv4. UUIDs are just 128-bit values. They might be conventionally encoded for humans as hex, but storing them as 36-byte (plus a few more for length) strings is a pointless waste of both space and performance.
  - Kesty 2y ago
    They don't have logs and commit directly to production 10/20 times a day. I don't think 128 bits vs 36 byte performance it's a main concern right now
    - bombela 2y ago
      It is most likely not a performance issues right now, but every pessismisation compound and catch up to you eventually. 36B vs 16B today, tomorrow you need an array of it, and now it isn't cache aligned, and more than twice the overhead. Most likely instead of manipulating a 36B fixed length string, it is handled as a dynamic string, for extra runtime memory allocations, most likely consuming at least 64B per allocation. Etc etc. Do this all over the codebase and now you know why all the moderne software is a sloth on what was a supercomputer 30y ago.
    - stouset 2y ago
      Probably not, but this is something that would have taken all of ten seconds to get right. And the size and performance impact is multiplied at every tier of their application. It’s also not just the size itself. Despite being fixed-size in practice, these are variable-sized strings in application code which now means gajillions of pointless allocations and indirection for everything. There are a ton of knock-on performance consequences here, all on the most heavily-used columns in your data model. Worst of all should they actually succeed, this is going to be absolutely excruciating to fix.
  - sgarland 2y ago
    IFF they’re using MySQL (doubtful), it’s a common mistake due to there not being a native type, and needing to know to use BINARY(16) and casting the string back and forth in code. But in either case – MySQL or Postgres – they’ve still made the classic mistake of using a UUID as a PK, which will tank performance one way or another. They’ll notice right around when it starts to matter.

theamk 2y ago

They had 5 days... they knew after the first night

lawgimenez 2y ago

Experience should tell you to always take a hard look at anything UUIDs.

stouset 2y ago
Also facepalms here: UUIDs as strings and UUIDv4. UUIDs are just 128-bit values. They might be conventionally encoded for humans as hex, but storing them as 36-byte (plus a few more for length) strings is a pointless waste of both space and performance.
- Kesty 2y ago
  They don't have logs and commit directly to production 10/20 times a day. I don't think 128 bits vs 36 byte performance it's a main concern right now
  - bombela 2y ago
    It is most likely not a performance issues right now, but every pessismisation compound and catch up to you eventually. 36B vs 16B today, tomorrow you need an array of it, and now it isn't cache aligned, and more than twice the overhead. Most likely instead of manipulating a 36B fixed length string, it is handled as a dynamic string, for extra runtime memory allocations, most likely consuming at least 64B per allocation. Etc etc. Do this all over the codebase and now you know why all the moderne software is a sloth on what was a supercomputer 30y ago.
  - stouset 2y ago
    Probably not, but this is something that would have taken all of ten seconds to get right. And the size and performance impact is multiplied at every tier of their application. It’s also not just the size itself. Despite being fixed-size in practice, these are variable-sized strings in application code which now means gajillions of pointless allocations and indirection for everything. There are a ton of knock-on performance consequences here, all on the most heavily-used columns in your data model. Worst of all should they actually succeed, this is going to be absolutely excruciating to fix.
- sgarland 2y ago
  IFF they’re using MySQL (doubtful), it’s a common mistake due to there not being a native type, and needing to know to use BINARY(16) and casting the string back and forth in code. But in either case – MySQL or Postgres – they’ve still made the classic mistake of using a UUID as a PK, which will tank performance one way or another. They’ll notice right around when it starts to matter.