Make the structure visible.

Decisions that carry their context.

Architecture is a record of trade-offs. A service boundary is useful when the team can explain the responsibility it contains, its failure modes and the contracts it needs to preserve.

• Write down essential inputs and outputs.
• Identify dependencies that can fail independently.
• Document the simplest viable recovery path.

Start with the actual system rather than a diagram of the system you wish existed. Update the diagram only when it helps someone make a decision.

Reliability is a practical habit.

A small service can be reliable without a large control plane. The essentials are visible health, good failure messages, a recoverable state and a way to verify the service after a change.

• Distinguish degraded behaviour from complete failure.
• Keep verification close to the action that changes state.
• Prefer reversible changes where failure is likely to be costly.

Checks are useful when they identify a credible failure, not when they simply increase the number of green indicators.

Leave a trail others can follow.

A good runbook states the starting conditions, the command or action, what success looks like and when to stop. A design note explains why an approach was chosen and what evidence would justify revisiting it.

Documentation should not require the original author to sit beside the reader. It should also resist the temptation to tell a polished story that hides uncertainty.