Best of Architecture — December 2025

  1. 1
    Article
    Avatar of techleaddigestTech Lead Digest·21w

    Traits of a good Tech Lead

    Tech Leads are responsible for technical direction across three pillars: architecture (defining decisions, managing technical debt), quality (maintaining standards), and mentorship (enabling team growth). Good Tech Leads use written artifacts like RFCs and PoCs to structure decisions, actively negotiate technical scope with product stakeholders, and establish operating principles that enable autonomous decision-making. They generate team velocity through clarity, reduce ambiguity, and influence without authority. Key anti-patterns include making improvised decisions without documentation, overdesigning solutions, and centralizing knowledge instead of distributing it across the team.

  2. 2
    Article
    Avatar of tkdodoTkDodo·23w

    Designing Design Systems

    An experienced frontend engineer shares their perspective on building effective design systems, emphasizing that success requires more than visual design. The post outlines 30+ principles for creating robust design systems, covering API design, type safety, accessibility, composition patterns, performance, and developer experience. Key themes include balancing constraints with flexibility, prioritizing type safety and documentation, building for common use cases rather than edge cases, and treating adoption as a cultural challenge rather than purely technical.

  3. 3
    Article
    Avatar of nordicapisNordic APIs·18w

    A Software Architect’s Guide to API-First Strategy

    API-first strategy treats APIs as foundational contracts defined before code implementation, enabling parallel development, improved governance, and better security. The approach requires design-first methodology using OpenAPI specifications, RESTful principles, strategic versioning, and robust authentication/authorization. Key infrastructure includes API gateways for traffic management, IAM systems for access control, observability tools for monitoring, and emerging AI gateways for LLM interactions. Security must be integrated throughout the lifecycle with proper authentication (OAuth 2.0, OIDC), fine-grained authorization (RBAC, ABAC), input validation, rate limiting, and TLS encryption. Industries like fintech, retail, and healthcare demonstrate success through improved interoperability, faster innovation, and new revenue streams. The strategy is essential for AI-readiness, as autonomous agents require well-documented, discoverable APIs with clear semantic contracts.

  4. 4
    Article
    Avatar of advancedwebAdvanced Web Machinery·18w

    Why I prefer multi-tenant systems

    Multi-tenant architecture offers significant advantages even for single-customer systems. Key benefits include parallelizable integration testing through tenant isolation, production monitoring that mimics real user behavior without affecting actual clients, safe demo environments for sales and developers, and flexibility for future business evolution. The complexity overhead can be minimized using database-level features like PostgreSQL's row-level security, which centralizes tenant filtering rather than requiring it in every query.

  5. 5
    Article
    Avatar of systemdesigncodexSystem Design Codex·22w

    Top Microservices Patterns

    Four essential microservices patterns are explored: Database Per Service (each service manages its own data with well-defined APIs), Shared Database (multiple services access a common database, useful for migrations but with coordination overhead), API Composition (aggregating data from multiple services through in-memory joins), and CQRS with Event Sourcing (separating read and write operations while storing state as event sequences). Each pattern presents distinct trade-offs between isolation, performance, and implementation complexity.

  6. 6
    Article
    Avatar of zedZed·21w

    How We Rebuilt Settings in Zed — Zed's Blog

    The Zed team rebuilt their settings editor from scratch, moving from a distributed, macro-based architecture to a centralized, strongly-typed model. The refactoring consolidated scattered settings definitions into UserSettings and ProjectSettings types, treating configuration files as the organizing principle rather than implementation details. They enhanced their GPUI framework with automated focus handling through tab groups and local state management similar to React's useState. The project revealed architectural weaknesses (including an auto-update bug) but resulted in a cleaner foundation for future features.

  7. 7
    Article
    Avatar of architectelevatorThe Architect Elevator·21w

    Being an architect isn’t the sum of skills. It’s the product.

    Effective architects must master the intersection of multiple skill domains rather than simply accumulating separate capabilities. Architecture requires synthesizing technical expertise, communication skills, business understanding, and people management into a unified force-multiplying capability. The role demands being a technical communicator who can present complex trade-offs to executives, a technical leader who multiplies team effectiveness, and a platform builder who bridges business and technology domains. Success comes from the product of these skills working together, not their sum.

  8. 8
    Article
    Avatar of techworld-with-milanTech World With Milan·20w

    10 software essays that changed how I think

    A curated collection of 10 influential software engineering essays spanning 1989-2022, covering technology selection (Choose Boring Technology), type safety (Parse Don't Validate), refactoring strategy (never rewrite from scratch), monolith vs microservices architecture, team process health (Joel Test), API design principles, simplicity over perfection (Worse is Better), complexity management, quality-speed tradeoffs, and career positioning. Each essay is accompanied by personal lessons learned and practical applications, emphasizing pragmatism, simplicity, and business value over technical perfectionism.

  9. 9
    Article
    Avatar of threedotslabsThree Dots Labs·21w

    DDD: A Toolbox, Not a Religion

    Domain-Driven Design (DDD) should be treated as a flexible toolbox rather than an all-or-nothing methodology. Most software projects fail due to poor handling of business domain complexity, not technical challenges. The core principle is understanding and modeling the business domain well in code, with strategic patterns (like bounded contexts and core domains) being universally valuable, while tactical patterns should only be applied when they solve actual problems. Developers often over-focus on technical complexity and frameworks instead of domain understanding, leading to legacy code. The key is pragmatically selecting DDD patterns that address real issues in your specific context, avoiding both religious adherence and complete dismissal of the approach.

  10. 10
    Article
    Avatar of engineerscodexEngineer’s Codex·20w

    Everyone is a Staff Engineer Now

    AI coding agents like Claude Code are shifting engineering work from implementation to higher-level activities like architecture, planning, and code review. Skills traditionally associated with staff engineers—maintaining context across systems, managing asynchronous workflows, steering AI agents effectively, and reviewing code—are becoming baseline requirements earlier in careers. Junior engineers now operate at senior-level abstraction while seniors architect at staff-level scale. Success depends less on prompting AI and more on managing personal context, maintaining focus during agent runtime, and developing new workflows that treat AI as a junior engineer to delegate to.

  11. 11
    Article
    Avatar of convexConvex·21w

    Why ctx.db is changing, and what you should do about it

    Convex 1.31.0 introduces a breaking API change where db.get, db.patch, db.replace, and db.delete now require the table name as the first argument. This change improves API consistency, enhances security by preventing cross-table ID vulnerabilities, and paves the way for custom document IDs. Existing code remains functional but should be migrated using the provided ESLint plugin or standalone codemod tool, which automatically infer table names from TypeScript types.

  12. 12
    Article
    Avatar of lobstersLobsters·21w

    Gin is a very bad software library

    Gin is criticized as an overly complex Go web framework with massive bloat compared to the standard library. The framework requires over 1 million lines of code and 55MB of dependencies to accomplish what net/http does in 25,000 lines. Its API design violates Unix philosophy with enormous interfaces (gin.Context has 100+ methods), creates unnecessary abstraction layers that obscure control flow, and makes migration away nearly impossible once adopted. The article demonstrates how Gin's complexity provides no real benefit over using Go's standard library directly, while significantly increasing binary size, compilation time, and cognitive overhead.

  13. 13
    Article
    Avatar of threedotslabsThree Dots Labs·20w

    How to Know If your Software Is Overcomplicated or Oversimplified?

    Software complexity stems from two extremes: overengineering with unnecessary patterns and oversimplifying complex domains. Essential complexity is inherent to the domain and unavoidable, while accidental complexity comes from poor implementation choices. Simply saying 'keep it simple' is insufficient—achieving simplicity requires deliberate effort and matching architectural patterns to actual problem complexity. Red flags include inability to deploy daily, fear of making changes, and team dissatisfaction. The solution involves using defensive programming, avoiding dogmatic approaches, mixing simple and sophisticated patterns appropriately, and focusing on shipping fast with incremental changes rather than premature optimization.

  14. 14
    Article
    Avatar of foojayioFoojay.io·22w

    Building Systems That Know Why They Exist ~ When Data, Logic, and Intent Finally Align

    Requirements-as-Code (RaC) is an engineering discipline that treats requirements and business rules as executable data models rather than static documentation. By storing requirements as structured, versioned data in systems like MongoDB, software can maintain a living connection to its original intent throughout its lifecycle. This approach enables systems to interpret documented purpose at runtime, validate behavior against intent, and maintain semantic alignment between what software does and what it was meant to do. When combined with AI for natural language compilation, RaC creates systems that don't just execute code but understand why they exist.

  15. 15
    Article
    Avatar of seangoedeckesean goedecke·19w

    You can't design software you don't work on

    Generic software design advice is largely useless for real-world engineering work on large existing codebases. Effective design requires intimate knowledge of concrete implementation details, not abstract principles. The most valuable design discussions happen between engineers actively working on the system, focusing on specific subsystems, dependencies, and constraints. Generic advice has limited utility: guiding new projects, tie-breaking decisions, and ensuring cross-codebase consistency. Formal architect roles that design without implementation responsibility often fail because they lack the concrete understanding needed to create actionable plans. Engineers who design systems should be accountable for their success or failure.

  16. 16
    Article
    Avatar of kogancomKogan.com·22w

    Patterns & Best Practices in Event-Driven Systems — Kogan.com Dev Blog

    Event-driven architecture enables decoupled, scalable systems through five core patterns: event notification (lightweight signals), event-carried state transfer (self-contained payloads), event sourcing (immutable change logs), choreography (decentralized workflows), and orchestration (centralized coordination). Essential practices include implementing idempotency to handle duplicate events, using durable message streams for replay capability, versioning events explicitly, managing schemas through registries, naming events after business domain concepts, and tracking requests with correlation IDs for distributed debugging and observability.

  17. 17
    Article
    Avatar of selfhstselfh.st·21w

    Building Slink: Lessons from Creating a Self-Hosted Image Hosting Platform

    A developer shares architectural decisions and lessons learned from building Slink, a self-hosted image hosting platform. Key insights include choosing single-container deployment for simplicity despite scalability trade-offs, evolving features based on community feedback from r/selfhosted and GitHub issues, and tackling technical challenges like animated image processing and real-time notifications. The project prioritizes deployment simplicity and performance over feature richness, with development driven by actual user needs rather than predetermined roadmaps.

  18. 18
    Article
    Avatar of allthingssmittyMatt Smith·23w

    React has changed, your Hooks should too

    Modern React development has evolved beyond overusing useEffect. React 18/19 introduces better patterns for handling async data, including useSyncExternalStore for subscriptions, useDeferredValue for performance optimization, and useEffectEvent for stable callbacks. The shift emphasizes keeping derived state in render, using effects only for true side effects, and building custom Hooks for encapsulation. Server Components and data-first render flows are changing how developers structure applications, moving away from Swiss Army knife useEffect patterns toward cleaner, more maintainable architecture that separates domain logic from UI concerns.

  19. 19
    Article
    Avatar of devtoDEV·20w

    My OSS Stalled for 3 Months Because of Misguided Vibe Coding—This Is the Full Reboot Story

    A developer shares their experience recovering from a 3-month project stall on diffx, a structured-data diff tool. The root causes included monorepo complexity, over-sharing CI/CD infrastructure across multiple projects, premature multilingual documentation, and quality issues from AI-assisted "vibe coding" without proper verification. The recovery process involved quarantining existing code, manually verifying functionality, writing specs from scratch, rebuilding tests based on specs rather than implementation, and splitting the monorepo into separate language-specific repositories. Key lessons include the importance of spec-driven development with AI, two-stage release workflows, and having the courage to delete broken artifacts rather than clinging to sunk costs.

  20. 20
    Article
    Avatar of logrocketLogRocket·22w

    tRPC vs oRPC: Which is better for your next TypeScript project, and why?

    tRPC and oRPC are both TypeScript RPC frameworks offering end-to-end type safety, but serve different needs. tRPC excels in TypeScript-only environments with minimal setup and instant type inference. oRPC extends this with built-in OpenAPI generation, enabling REST compatibility and multi-language support. The article provides hands-on demos of both frameworks, showing schema validation with Zod, type synchronization between client and server, and practical implementation patterns. Choose tRPC for internal TypeScript apps; choose oRPC when you need API documentation, external integrations, or polyglot team support.

  21. 21
    Article
    Avatar of seangoedeckesean goedecke·19w

    Nobody knows how large software products work

    Large software systems at tech companies are poorly understood even by their own engineers. Complex features like enterprise controls, localization, and compliance requirements create intricate interactions that affect every new feature. Documentation struggles to keep pace with rapid changes, and many system behaviors emerge unintentionally from default choices. Engineers who can reliably answer questions about how software works are rare and valuable, as most prefer writing code to explaining it. The ability to investigate and understand existing systems is a distinct skill from coding, requiring comfort with uncertainty and summarization.

  22. 22
    Article
    Avatar of salesforceengSalesforce Engineering·22w

    How Agentforce Achieved 3–5x Faster Response Times

    Salesforce's Forward Deployed Engineering team optimized Agentforce for a multi-brand retailer by separating deterministic logic from LLM reasoning, moving hierarchical processing from prompts to Apex code. They consolidated multi-stage LLM calls into single passes and optimized Data 360 retrieval, reducing end-to-end latency by 75% (approximately 20 seconds). The team chose a multi-agent architecture over a unified model, enabling brand-specific conversational experiences while maintaining a shared foundation that accelerated subsequent brand deployments by 5x.

  23. 23
    Article
    Avatar of atomicobjectAtomic Spin·21w

    Syncing Data: Choosing the Right Strategy

    Data synchronization between external systems and a central platform requires careful strategy selection. Pull-based syncing offers reliability and predictability through scheduled jobs with metadata tracking, ideal for non-urgent data but prone to staleness or rate limiting. Event-driven incremental sync uses lightweight checks like HEAD requests and ETags to detect changes and update only modified records, providing near real-time responsiveness with reduced API calls. Most effective architectures combine both approaches: lightweight change detection, delta syncs for updates, and periodic full syncs as safety nets. Treating syncing as a core architectural concern with proper observability, retry logic, and intelligent prioritization creates maintainable, resilient systems.

  24. 24
    Article
    Avatar of lobstersLobsters·18w

    A SOLID Load of Bull

    A critical examination of the SOLID principles in object-oriented programming. The Liskov substitution principle is endorsed as mathematically sound and universally applicable. The open-closed principle is deemed obsolete in modern languages with proper tooling. The single-responsibility, interface segregation, and dependency inversion principles are criticized as misguided heuristics that lead to over-engineered code. The author argues for focusing on module depth (small interfaces with substantial implementations) rather than blindly following SOLID, and advocates injecting dependencies only when genuinely necessary rather than as default practice.

  25. 25
    Article
    Avatar of hnHacker News·21w

    Goodbye Microservices

    Twilio Segment migrated from 140+ microservices back to a monolithic architecture after microservices created unsustainable operational overhead. The team consolidated separate repos and queues into a single service with a unified test suite using Traffic Recorder. This transition dramatically improved developer productivity (46% more library improvements), reduced deployment complexity from 140+ services to one, and simplified scaling. While accepting trade-offs like reduced fault isolation and less effective in-memory caching, the monolith proved more suitable for their server-side destinations pipeline.

See all Architecture archives