An architectural doctrine for NestJS projects: a breakdown of typical codebase degradation scenarios and the structural constraints that keep them from emerging as the feature set grows. Now let's see what this "decomposition into services" actually costs on a horizon a little longer than one sprint. Our product already has a FollowsService — it lives tidily in its own module, drops "followerId → targetUserId" relations into its table, and knows nothing it shouldn't. In parallel — UsersModule , with the pieces split out into separate services: UserPrivacyService and UserSettingsService . Each is responsible for its own facet of the user. Single responsibility, the implementation is clean, review is a celebration. Then complaints start coming in through support: strangers send all kinds of nastiness in DMs, users want to hide their profiles from random eyes. The request is clear, human — the PM picks it up: we'll do private accounts.…