In Defense of Simple Architectures (2022)
Engineers weigh the benefits of “boring,” monolithic architectures against complex microservice-heavy stacks, arguing that most businesses can scale quite far with a single well-structured app backed by a relational database. Many blame resume-driven development, hype around FAANG-style patterns, and weak technical leadership for unnecessary complexity that hurts reliability, slows delivery, and burns out teams. Others note that microservices and event-driven designs can be justified for organizational scaling or specific performance needs, but only when driven by real constraints rather than fashion.
Simple vs complex architectures
- Many commenters endorse “boring” stacks (Rails/Django or Python+Postgres, SSR templates + htmx, single VPS) as sufficient for most CRUD/business apps, especially B2B.
- They stress that simple systems are easier to reason about, maintain, debug, and staff for; “old and reliable” often beats “new and shiny”.
- Others argue that what counts as “simple” is subjective: containers, k8s, GraphQL, or async I/O can feel simple to those familiar with them and complex to others.
Monoliths, microservices, and event sourcing
- Strong support for starting with a monolith, structured with clear modules and boundaries; many claim a disciplined monolith can scale very far.
- Critics of microservices say they don’t reduce complexity, they just move it over the network, making consistency, transactions, debugging, and deployments harder.
- Pro‑microservices voices frame them as primarily an organizational and coordination tool: enabling independent teams, isolated failure, and targeted scaling.
- Event sourcing/CQRS is proposed as “microservices done right” by some, but others call it immature and complex (PII deletion, replay semantics, determinism).
Tech choices: Python, GraphQL, Kubernetes
- Some think the described stack (Python monolith + Postgres + queues + GraphQL + k8s + custom protocol) is not truly “simple” and question several of those choices.
- Debates about Python in finance: static typing is seen by some as vital for money-handling; others argue modern Python tooling (mypy, C FFI, rich libs) is adequate.
- GraphQL gets both praise (cuts REST endpoint sprawl, shared schema, strong typing) and pushback (conceptual complexity, size of responses, not strictly needed over REST).
- Kubernetes is seen by some as needless overhead for small teams; others say a managed k8s cluster can be a straightforward way to run a “plain” three‑tier app.
Human and organizational factors
- Many blame complexity on resume‑driven or “magpie” engineering: adopting Kafka/microservices/cloud/etc. to learn or impress, not to solve real problems.
- Others note that exploration has value, but should happen in prototypes, side projects, or constrained contexts, not core production systems.
- Several emphasize that architecture must match org reality: team size, experience, ownership, and incentives matter more than specific patterns.
Scale, performance, and “you won’t need it”
- One camp argues synchronous I/O and single DBs handle “millions of requests per month” easily; scale with bigger boxes before distributed complexity.
- Another camp warns that blocking I/O and poorly chosen stacks can fall over even at low volume, especially when downstream latency spikes.
- There’s broad agreement that premature “building like Netflix” has sunk or slowed many companies, but also that under‑design can be costly to fix later.
Careers, incentives, and value
- Some worry that focusing on “boring tech” harms career prospects because hiring often filters by buzzword stacks.
- Others counter that quantifiable business impact (“saved X, enabled Y revenue”) is more compelling at senior levels than tech bingo.
- Several note misaligned incentives: cheap capital and growth‑at‑all‑costs encouraged wasteful complexity; tying engineers closer to business outcomes is suggested as a corrective.