There is no such thing as stateless

  1. Any component of the solution can (and will!) fail at any time, and for a reason you didn’t anticipate.
  2. If the component fails, whatever it was doing will be left in limbo, (your exception handlers will fail too at some point)
  3. If one part of a process depends on any other part of the process in any way, then this is state, and you probably can’t avoid it.
  4. What should happen if things fail? can you afford to restart everything? is your process idempotent? What if it completed but failed during post-job tasks?
  1. Make sure that that indicator/flag/storage can be updated atomically (or as nearly atomically as possible) If you can’t make it happen atomically, find a different way (It’ll make your life easier)
  2. If you’re storing an indicator, store it in the right place, don’t attach data that’s related to one part of the system in a container that’s used for a different part. This is bad design, and leads to horrible coupling.
  3. Similarly, trying to infer state from other indicators is usually a bad idea. If something is waiting for a precondition to be met before doing something, unless that precondition is really simple, and can be relied upon to be toggled atomically, then add a separate atomic flag that gets toggled at the right time.

--

--

--

Tech Lead

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Steve Stagg

Steve Stagg

Tech Lead

More from Medium

Struggling to Find the Right Fit for a Data Role? Try Easing Up on the Cloud Jargon.

Thoughts Over an Annoying Production Issue

Cheat Sheet for leaders

Implementing Availability SLOs in Typeform