Deciding not to split a service, and writing down why

The reporting module is slow, memory-hungry and occasionally takes the application down, which is a real argument for extracting it and not a sufficient one.

what extraction would fix:
  resource isolation — a report cannot exhaust the
  web workers' memory

what it would cost:
  a network hop for data currently read directly
  a second deployable, on a team of four
  eventual consistency in a report that is expected
  to be current

what we did instead:
  a separate process pool on the same codebase, with
  its own memory limit and its own queue.

revisit if: the team grows past eight, or the report
data stops being the transactional data.

The revisit condition is the part that makes this a decision rather than a delay. A separate process pool got the isolation, which was the actual problem, for a day of configuration — the same code deployed twice with different limits is a well-known pattern and it is under-used because it does not sound like architecture.