Good system design

Logging, Metrics, and Observability

• Strong agreement that pervasive logging of major business decisions and basic metrics pays off during incidents.
• Recommended pattern: log aggressively, but use aggressive filtering and short retention to control cost and noise.
• Observability value comes less from “having logs” and more from being able to filter, search, and correlate them.

State, Microservices, and Org Design

• Biggest pain is synchronizing multiple stateful systems, especially with bidirectional flows; a single source of truth is preferred.
• Monotonic or owned state (one clear owner, others as readers) is seen as safer than widely mutable shared state.
• Criticism of microservices used to mirror org charts rather than business/technical needs; this can “codify organizational inefficiency” and add needless network latency.
• Some argue architecture should follow business and processes, not team boundaries; others warn that doing architecture before processes emerge leads to overengineering.

Database Design: Booleans, Timestamps, Audits, and Soft Deletes

• Debate over the “never store booleans” meme. Many see timestamps/enums/integers as more future-proof for flags and status; others say booleans are fine when they truly model a binary outcome.
• Soft deletes are viewed by some as lazy substitutes for real auditing and often a source of complexity; others find them practical for recovery and “what changed when” analysis.
• Audit tables: disagreement whether they’re “dumb extra sources of truth” or simply immutable change logs alongside the primary tables. Consensus that you must be clear which layer is authoritative.

Joins, ORMs, and Where Logic Lives

• Default advice “let the DB do joins” is widely supported, but several describe real cases where app-side joins or denormalized JSON blobs were faster and simpler.
• ORMs are polarizing: they reduce CRUD boilerplate but can hide performance issues (N+1, oversized joins). Many advocate a mixed approach: ORM for simple stuff, raw SQL or views for complex queries.
• Views are broadly liked as stable, check-in-able abstractions; stored procedures are seen as powerful but often harmful to maintainability, tooling, versioning, and team understanding.

Schema Flexibility vs EAV/JSON

• Strong dislike for generic EAV (“keys/values”) and polymorphic “classifier” tables that obscure meaning and push complexity into application code.
• Preference for many explicit, human-readable tables and conventional relations; JSON/JSONB is accepted for genuinely open-ended or hard-to-schema data, but not as the default.

Caching, Replication, Queues, CQRS, Event Sourcing

• Using read replicas is endorsed, with recognition that replication lag must be handled (timestamps, “fill in in-memory,” or routing some reads to primary). Some find these workarounds fragile.
• Queues: many defend managed queues as simple and robust; skepticism toward rolling your own queue or misusing DB tables and cron where a queue fits naturally.
• CQRS gets mild shade in the article, but some note the recommended pattern of “one writer service, others read/emit events” is essentially CQRS-like.
• Event sourcing is praised by a few as conceptually solving many problems (events, auditing, distribution) but acknowledged as heavy and rarely justified for small projects.

Simplicity, Overengineering, and Interviews

• Strong cultural theme: good design is “boring,” underwhelming, and optimized for maintainability and safe change, not for intellectual impressiveness.
• Many lament that promotions, resumes, and system design interviews often reward complexity, leading to “LinkedIn-driven” or “resume-driven” architectures (microservices, K8s, exotic datastores) where a monolith + Postgres would suffice.
• Several commenters describe answering interview system-design questions with pragmatic simplicity and being penalized because interviewers wanted elaborate distributed designs.

Limits of Generic Advice and Context Dependence

• Some criticize the article for offering rules-of-thumb without clearly stating its context (traffic levels, team size, constraints), arguing that “good design” is only meaningful relative to requirements.
• Others defend it as a practical, mid-level catalogue of tradeoffs that sits between theory-heavy books and oversimplified “use Cassandra for a billion users” checklists.
• Broader systems thinking (humans, org design, socio-technical feedback loops) is noted as largely missing from the article and many “system design” discussions.