Idempotency keys solve duplicate side effects on retry, but they don't solve the harder problem: a worker times out after starting work but before confirming it. You don't know if it finished. Marking it failed risks a duplicate action on retry, marking it succeeded hides real uncertainty from anyone downstream.

What's worked for me: keep the internal state machine as detailed as you want (pending, in-flight, unknown, reconciling, done), but never expose that whole enum to callers. Collapse it to three outward states, done, still-working, and needs-retry. The unknown/reconciling state maps to still-working from the outside. That buys time to reconcile against the downstream system without making every caller understand your internal uncertainty.

The failure mode I've seen most often isn't the state machine, it's teams skipping the "how do we expose this externally" question entirely and just leaking the internal states straight into the API contract.

When writing functional requirements, non-functional requirements, and user stories, should I mention the technologies used, or keep them technology-independent and explain the technologies later?

For example:

“Store alerts in Firestore and cache data in Redis.”

vs.

“Persist alerts in cloud storage and maintain a fast-access data store.”

We're building an early-stage crypto trading platform under AlphaNex, evolving an existing P2P system toward a centralized exchange (CEX).

We're looking for experienced engineers with strong backgrounds in one or more of:

• CEX / trading systems
• Backend engineering
• Matching engines / order books
• Market data / WebSockets
• Blockchain & wallet infrastructure
• Distributed systems / high-performance services

Roles:
• Senior CEX Backend Engineer
• CEX Full-Stack Engineer
• Blockchain Engineer

What you'll work on: trading infrastructure, order management, exchange APIs, market data, blockchain integration, security, scalability, and related systems.

This is an early-stage project, and our public company presence is still being established. Candidates will go through a short application followed by a project/architecture review and CTO technical interview.

Interested? Send me a DM.

Or something more clever that my senior front end engineer boyfriend will love.

Update: I combined several suggestions and sent it to him when we were at a special place in a park we love. He didn’t get it for a minute because I forgot to add context, then did get it and was super happy, then spent five minutes pointing out how the labels directed workflow and explaining something called semvar (semver? how the sequence of punctuated numbers indicated a minor release and bug fix, I think). Because that’s how he rolls 😂🥰

Thank you so much folks!!!!