Compensation is a business action, not a database undo
A distributed workflow cannot usually erase every completed step. Define the corrective business action for each effect and make unresolved states visible.
Read articleAI implementation, software architecture and cloud operations for teams worldwide.
456 articles
Page 2 of 26
A distributed workflow cannot usually erase every completed step. Define the corrective business action for each effect and make unresolved states visible.
Read articleFiltering an API request by organisation is not enough if jobs, caches or exports lose that context. Carry the boundary through every path that reads or changes tenant data.
Read articleA message can remain valid JSON while its meaning changes. Define the business fact, its timing and its replay behaviour before other systems depend on it.
Read articleDecide how old a value may be and what happens when that limit is exceeded. Faster reads are useful only while the result remains suitable for the task.
Read articleDuring a rolling release, old and new code share the database. Design the transition around that overlap before removing or reinterpreting stored data.
Read articleConcurrency control protects the rule shared requests depend on. Start with that rule, then choose conditional writes, locks or transaction isolation to enforce it.
Read articleMoving traffic is only part of a migration. Decide where new business changes are accepted and how that authority moves without creating conflicting histories.
Read articleA landing zone should make safe deployment routine. Define ownership, identity and operating boundaries before adding shared services that every workload must depend on.
Read articleA restore is complete when a verified business workflow works again. Recovering files alone does not restore identity, configuration or external dependencies.
Read articleA second application region is not a complete recovery path. Authentication, keys, integrations and write ownership need the same rehearsal as compute and data.
Read articleInfrastructure drift is a difference to investigate, not an instruction to overwrite production. Establish why the live state changed before choosing what the next deployment should do.
Read articleSending a few requests to a new release limits initial exposure. It becomes a useful safety mechanism only when evidence determines whether to continue, pause or recover.
Read articleA service indicator should describe the experience the application is meant to provide. CPU usage and healthy processes help explain failures, but do not establish that a task succeeded.
Read articleUpdating a secret store is one step in a distributed change. The target service and every consumer must agree on which credential works before the old one is retired.
Read articleA lost response leaves the outcome uncertain. Keep an operation record and a reliable mapping to the Xero organisation and resource before retrying creation.
Read articleTwo systems can share a customer record without both owning every value. Decide which source controls each field and how legitimate conflicts are resolved.
Read articleKeep the receiver short, but do not return success before accepted work is durable. Separate delivery receipt from the business effect that follows.
Read articleA retry delay inside one request does not coordinate a fleet of workers. Model the provider's shared limits and decide which work receives the available capacity.
Read article