A modular monolith needs boundaries the code can enforce
One deployable application can contain clear business modules. The separation becomes useful when callers cannot casually bypass each module's rules and data ownership.
Read articleAI implementation, software architecture, cloud operations and Australian technology policy.
100 articles in Software architecture
Page 1 of 6
One deployable application can contain clear business modules. The separation becomes useful when callers cannot casually bypass each module's rules and data ownership.
Read articleA business write and a message publish can fail independently. Save the intention to publish in the same transaction as the business change, then deliver it through a recoverable worker.
Read articleWhen a response is lost, the caller needs a way to repeat the request without repeating its effect. Give the intended action an identity that survives every attempt.
Read articleCompatibility includes behaviour, defaults and error handling as well as field names. Review what older callers rely on before changing the contract.
Read articleA 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 articleDefine the operation other features need, then hide the rules and persistence behind it. This gives the module a boundary that can survive internal changes.
Read articleKeep the order update and outbox insert in one transaction. Then give the publisher stable event identities and a clear recovery path for uncertain delivery.
Read articleStore the key, account scope and material payload together before executing. Matching retries can reuse the outcome, while conflicting reuse receives an explicit error.
Read articleIntroduce a field in stages so older callers remain valid while newer ones adopt it. Define omission and conflict behaviour before changing validation.
Read articleDesign the recovery record from the actual side effects. A list of service calls does not tell the coordinator what can safely be corrected after failure.
Read articleA worker needs an explicit, trusted scope for the job it executes. Save that scope at submission and validate it again according to the workflow's authority policy.
Read articleBuild an event contract around one interpretation. A consumer needs to know whether it should replace a view, apply a transition or fetch more information.
Read articleInclude every input that changes a cached response. A resource identifier alone is rarely enough for tenant data, translations or filtered views.
Read article