Keeping It Idempotent
One thing I have come to respect a lot more over time is idempotency.
This is not meant to be a deep dive. I just want to keep it short and share how I have come to think about it from experience.
I started paying a lot more attention to this in previous jobs, especially around flows where the same request might come in again and the app still needed to land in the same state. Once you have had to figure out why the same user exists twice in your system, the idea stops feeling abstract.
A practical example
One simple way to think about it is syncing a user from an external system into your own app. That one feels real to me because in my current job we pull user data from third-party systems into ours.
If the same user gets synced again, maybe because the source system retried, the job ran again, or the sync was restarted, I still want one user in our system for that external identity. I do not want duplicate local users just because the same upstream data showed up again.
The operation might run again, but the final state should still make sense. If the same request can show up again, your system should still land in a sensible state. That is really the point.
Conclusion
I hope you enjoyed this post. If you have your own idempotency story, I would love to hear it.