It's not microservice or monolith; it's cognitive load
Cognitive load, not buzzwords like “microservices” or “monolith,” is framed as the real constraint on software architecture choices. Commenters argue that both patterns can succeed or fail depending on team size, domain boundaries, tooling, and organizational incentives, with many warning that microservices add operational and coordination complexity that small or immature teams can’t handle. Several voices emphasize starting with product needs and clear modular design (often via a well-structured monolith) and only moving to distributed services when scale, team structure, or autonomy requirements truly demand it.
Meta: HN Ranking & Suspicion
- Some comments question how the post reached the front page quickly with few points/comments.
- The ranking algorithm is described as favoring fresh posts with rising points; others speculate about bots or manual boosting/deranking, but this remains unproven and contentious.
Cognitive Load as Design Lens
- Many like “cognitive load” as a human-centered way to think about architecture.
- Disagreement over measurability: some say it can’t/shouldn’t be quantified; others note human-factors research in other domains.
- Misinterpretation of “design to maximum cognitive load”: some read it as pushing teams to their limits; others as “don’t exceed what teams can actually handle.”
- Examples from oil refineries and medical software highlight that undocumented, multi-service “data refineries” can exceed human comprehension and create real risk.
Microservices vs Monolith: Tradeoffs
- Strong view: architecture should follow sound design (autonomy, clear boundaries) rather than arbitrary targets like “N services per team” or “always a monolith.”
- Several argue microservices are primarily an organizational/deployment strategy; technically, a single-process or modular monolith is usually simpler, faster, and more reliable.
- Microservices can work well when: boundaries are well-designed, services are independently testable, CI/CD and observability are strong, and teams are large.
- Many report failure modes: too many services, hard-to-change interfaces, cross-team coordination bottlenecks, long debugging chains, and “distributed monoliths.”
Team Structure, Conway, and Team Topologies
- Debate over whether microservices exist to “comply with” or “embrace” Conway’s Law vs treating it as a warning.
- Some see service-per-team and “Team Topologies”-style autonomy as helpful; others say it encourages fiefdoms, fragmentation, and skyrocketing cognitive load across teams.
- Multiple comments stress that incentives, leadership, and soft skills matter more than the chosen pattern.
Componentization, Modularity, and Middle Ground
- Many emphasize that modular monoliths can achieve clear boundaries via libraries, packages, and strict interfaces.
- “Monolith vs microservices” is seen as a false binary; there’s a spectrum: single-process modular apps, “mesolithic/gabion” designs, shared DBs with strict ownership, and selectively extracted services.
- A long subthread discusses extreme partitioning (hundreds of small components/repos) vs a single monolith, with supporters citing small-batch productivity and critics citing maintenance and perceived overengineering.
Product vs Architecture Priority
- Several founders argue early-stage startups should prioritize product discovery and speed; scaling/rewrites are a “good problem” few reach.
- Others counter that long-lived systems demand ongoing refactoring, simplification, and respect for essential vs accidental complexity.
Practical Ways to Reduce Cognitive Load
- Suggested tactics: strong encapsulation, well-defined APIs, bounded contexts, good documentation, fewer languages/tech stacks, and extracting self-contained libraries.
- Repeated theme: you can’t avoid complexity, but you can choose where it lives and how much of it each person must hold in their head.