Ask a coding assistant to design a system in the abstract and it can produce a catalogue of plausible components. Start instead with the existing system, the pressure it is under, and the change you need to make. Architecture is a choice under constraints.
Write down the forces
Describe the current data flow, ownership boundaries, failure modes, and operational capacity. Separate measured limitations from anticipated growth. A hypothetical traffic spike should not silently become the main reason to add a new service.
Require a real alternative
Compare the proposed design with a smaller change and with leaving the structure alone. Ask who operates each option, how it fails, and how data moves during migration. A useful alternative addresses the same requirement, even if it makes different tradeoffs.
Keep a compact record
Decision: Keep report generation in the existing worker.
Context: Jobs already use its retry and scheduling path.
Alternative: Add a separate report service.
Consequence: Shared capacity needs explicit monitoring.
Revisit when: Report jobs repeatedly delay other work.Make the uncertainty visible
Have the assistant list which assumptions depend on code it has not inspected or measurements you have not taken. Investigate the assumption that could reverse the decision first. Keep the record beside the implementation so future edits inherit the reasoning as well as the design.
