nhoughto

True you could rotate by persisting the old value and complicate your lookup/join process, not my idea of an acceptable solution but yep totally possible and worth it for some set of tradeoffs.

Yep have used an approach just like that, worked quite well if you have a strong pattern to easily translate from one to the other. Gives you an id with the right properties for internal use, efficient indexing etc, and in its encrypted form gives you the properties you want from an external identifier being unpredictable etc, all from one source id.

It is true that now your encryption key is now very long lived and effectively part of your public interface, but depending on your situation that could be an acceptable tradeoff, and there are quite a few pragmatic reasons why that might be true as has been described by other comments.

Edit: you can even do 64bit snowflakes internally to 128bit AES encrypted externally, doesn’t have to be 128-128 obvs

very neat! definitely will come in handy.

In startup/mvp land it is a genuine tension between shipping it and over engineering at different extremes. It is quite possible to correctly think “this is bad engineering” and still ship it and all of those decisions to be correct. Bootstrapping and early stage code almost inevitably gets replaced so isn’t worth polishing too much. It feels totally wrong and requires some real soul searching for some engineering personalities but in the end it’s optimizing for the most important outcome, the actual business success.. speaking from exp of not doing a few times and then the whole thing failing..

Yep

Couple of, retrospectively, often almost incoherent sentences to capture top of mind state when I give up because it’s late.

I’ll write this gibberish comment here because I’ll definitely forget what I was doing and if the compile fails I probably won’t miss it!

Watch out firebolt.io sounds like CH has solved the ease of deployment problem!

That’s the cell architecture, so N data plane clusters aka cells, testing qualifies a cell to meet a cert perf level and you horizontally scale out more cells to meet demand.

Whilst hoping a single customer doesn’t exceed the limits of a cell =)

Interesting idea, naively that seems possible based on other non chess example prompts I’ve seen. Would be a great way to understand it’s tracking of state throughout the game

I feel that, I’m often doing a thing thinking “this is wrong it won’t work for xyz” but continue because I want it to work, only to give in to what I knew a day+ ago but refused to acknowledge. It would definitely be more efficient to listen to.. myself, and kill things early.

Yep we talked to FE and they were great, but most selling processes require doco, finances, code review, walkthroughs, hand holding, explanations etc. “write down all the shit you’ve just known or learnt in the last 8 years” to make some multiple of revenue (not necessarily >1), with no guarantee of the sale closing and having to repeat.

Too. Hard. That plus the complexity of other things in our lives to deal with means that some $ just to see through a sale isn’t worth it.

The software is the thing we built and a testbed which we cut our teeth on, and learnt so much, took that knowledge and folded into other newer projects an incredible platform for learning and iteration, but we’ve moved on to bigger and better already so don’t too feel bad about turning it off (it was our first baby tho..).

Hit its effort vs scale limit and we’ve got more pressing things to spend time on. We could grow it but the result isn’t worth the effort compared to cost benefit of other endeavors we’ve got on the go (big tech jobs) and more recent time needs (young families).

Learnt a bunch across so many dimensions and set us up for ongoing success with that knowledge, but this specific thing has no future and selling it appeared too hard.

It was on autopilot for sure but that baked in an assumption that customers self solved, and had no new needs. We felt bad that we were delivering a decaying service to users in silence, users could use an alternative and get better service for their $ (in theory) and we would stop taking $ for what we see as delivering a subpar result.

Great details! Why only half the time though? What is the behavior the rest of the time?

Aw I was reading this thinking I wonder what incredible result it came up with! And bam, didn’t work! I guess that I was surprised it didn’t work is a testament to the other amazing results.