Best of Architecture — January 2026

1
Article
DEV·16w
Microservices Are Killing Your Performance (And Here's the Math)
Microservices introduce significant performance overhead compared to monolithic architectures. Network calls add 1,000-5,000x latency versus in-process function calls, resulting in 50-150% higher latency, 300% more resource usage, and 2-3x infrastructure costs. Benchmarks show microservices suffer from cascading failures (5x more downtime), database connection exhaustion, and serialization overhead. The article argues microservices solve organizational problems (team autonomy, independent deployment) rather than technical ones, and recommends modular monoliths for most applications. Microservices only make sense for organizations with 50+ engineers, independent scaling requirements, technology diversity needs, or compliance isolation.
436
39
2
Article
stitcher.io·16w
Processing 11 million rows in minutes instead of hours
A developer optimized their blog's analytics system to process 11 million events, improving performance from 30 to 14,000 events per second through systematic changes: removing unnecessary database sorting, reversing nested loops, ditching the ORM for raw queries, replacing closures with while loops, fixing framework serialization overhead, and using indexed ID-based pagination instead of offsets. The rebuild time dropped from 50 hours to 10 minutes per projector.
276
4
3
Article
Wix Engineering·18w
Why I Stop Prompting and Start Logging: The Design-Log Methodology
The Design-Log Methodology addresses the "Context Wall" problem in AI-assisted coding by maintaining version-controlled markdown documents that capture design decisions before implementation. Instead of repeatedly explaining architecture to AI, developers create immutable design logs in a ./design-log/ folder that document problems, questions, answers, and implementation plans. The AI reads these logs first, asks clarifying questions in the document, and only codes after design approval. This approach transforms AI from a code generator into an architectural partner, enabling simple prompts, preventing context drift, and creating traceable implementation history.
242
11
4
Article
John Liter·15w
Why I Choose to Build My Own Systems Instead of Paying for Apps
Building custom systems instead of relying on commercial apps offers strategic advantages: full data control, tailored workflows, reduced complexity, and independence from external platforms. While not always cheaper or faster initially, custom systems become compounding assets that grow with your needs and embed institutional memory. This approach shifts thinking from features to processes, focusing on inputs, transformations, outputs, and automation opportunities. The real value lies in developing deep workflow understanding and maintaining capability rather than just convenience.
213
39
5
Article
DEV·18w
My 2026 Tech Stack is Boring as Hell (And That is the Point)
A senior engineer advocates for choosing simple, proven technology over complex, trendy solutions. The author describes moving from microservices and Kubernetes to a monolithic architecture running on a single VPS with SQLite or Postgres, arguing that most applications don't need the complexity of distributed systems. The piece emphasizes that users care about working features, not architecture choices, and that boring, battle-tested tools allow developers to ship products faster while maintaining lower costs and cognitive overhead.
176
10
6
Article
Stack Overflow Blog·18w
Documents: The architect’s programming language
Software architects distinguish themselves from senior developers by mastering the deployment of ideas through documentation rather than just code. The architect role requires organizing people and consensus through written documents like architecture overviews, dev designs, project proposals, developer forecasts, technology menus, problem statements, and postmortems. Effective technical documentation relies on bullet points for information density, headers for organization, and chronological rather than topical filing. Documents should be treated as point-in-time artifacts that serve specific purposes rather than continuously maintained resources. The key insight is that the biggest bottlenecks in software development are people problems around communication and decision-making, not technical ones.
132
3
7
Article
The Polymathic Engineer·15w
Software Design Principles That Matter
Three fundamental software design principles help build flexible, maintainable code. The Open-Closed Principle advocates for code that's open for extension but closed for modification, using interfaces to separate varying parts from stable ones. Dependency Injection reduces coupling by providing dependencies through constructors rather than creating them internally. Inversion of Control removes responsibilities from classes by letting frameworks control application flow while your code acts as plugins. Together, these principles reduce complexity and make code easier to test, extend, and maintain.
124
4
8
Article
Valdemar·14w
The market is now pushing "Duolingo for coders."
Gamified coding education platforms that teach syntax through mobile apps and streak rewards are insufficient in an era where AI agents can deploy entire systems. The focus should shift from memorizing syntax to learning system architecture and leveraging AI tools effectively. Success requires architectural thinking rather than accumulating coding badges.
100
47
9
Article
stitcher.io·14w
Once again processing 11 million rows, now in seconds
A PHP developer optimizes a script processing 11 million database events, improving performance from 50k to 1.7M events per second through incremental changes. Key optimizations include combining SQL inserts, moving calculations from MySQL to PHP, eliminating object instantiation in favor of raw arrays, and removing JSON deserialization by using direct database columns. The journey demonstrates the trade-offs between code convenience and raw performance, with the final implementation processing data in seconds rather than days.
99
1
10
Video
Zoran Horvat·16w
Stop Adding a Service Layer to Every Web API
Service layers are often unnecessarily added to Web APIs. A service layer is only justified when orchestrating changes across multiple independent mutable systems (like a database and payment gateway). Most Web APIs write to a single database and read from multiple sources, making a service layer pure overhead. The one-to-one relationship between endpoints and service methods creates boilerplate code for DTO mapping, error translation, and localization without providing architectural value. The decision is simple: if your API doesn't orchestrate multiple transactional boundaries, skip the service layer and implement logic directly in endpoints.
97
10
11
Article
Josh Hornby·15w
What is a Tech Lead?
The tech lead role varies significantly across companies. At larger organizations, it typically focuses on technical direction without people management. At smaller companies, tech leads handle both technical leadership and people development. The hybrid role encompasses three core areas: setting technical direction and architecture standards, helping engineers grow through mentoring and code reviews, and ensuring delivery by unblocking teams and managing scope. Success means becoming less essential over time by building team capability rather than being a bottleneck. The role requires balancing competing demands between coding, mentoring, and delivery.
96
5
12
Article
Ayende @ Rahien·14w
API Design: Don't try to guess
When designing public APIs for libraries, avoid trying to guess user intent by inferring behavior from limited information. A code example shows an AddAttachment method that automatically determines content type from file extensions, which limits flexibility and forces library updates for new file types. Instead, let callers explicitly provide the information they already know. This approach prevents blocking users from doing what they need and reduces the need for library changes, especially important for externally shipped libraries where updates are slow to deploy.
95
5
13
Article
ByteByteGo·15w
How Netflix Built a Real-Time Distributed Graph for Internet Scale
Netflix built a Real-Time Distributed Graph (RDG) to track member interactions across streaming, gaming, and other services. The system processes millions of events per second using Apache Kafka for ingestion, Apache Flink for stream processing, and a custom Key-Value Data Abstraction Layer (KVDAL) built on Cassandra for storage. Netflix rejected traditional graph databases like Neo4j and AWS Neptune due to scalability limitations and operational complexity, instead emulating graph capabilities using key-value storage with adjacency lists. The architecture handles 8 billion nodes, 150 billion edges, 2 million reads/second, and 6 million writes/second across 2,400 EC2 instances, with each node and edge type isolated in separate namespaces for independent scaling.
88
14
Article
WunderGraph·16w
10 Principles for Designing Good GraphQL Schemas
GraphQL schema design should prioritize client needs over backend data models. Key principles include capability-based design (understanding what clients need to accomplish), making expected errors explicit through union types, careful nullability management to minimize blast radius, mandatory pagination for security and UX, and abstracting implementation details to allow backend changes without breaking clients. Schemas should match organizational structure—monolithic for single teams, federated for multiple teams. Assume fields can never be deprecated once published, especially for mobile clients. Use semantic nullability to distinguish between absent data, null values, and error-caused nulls.
86
15
Article
Planet Erlang·18w
Software Acceleration and Desynchronization
Software development acceleration creates desynchronization across interconnected work loops. When teams speed up individual tasks like code writing, they risk decoupling from slower but essential feedback cycles around operations, architecture, and organizational knowledge. This desynchronization accumulates as drift between mental models and reality, potentially leading to incidents that force rapid resynchronization. Strategic slowdowns in certain areas can actually accelerate overall system performance by maintaining necessary synchronization points. The drive for continuous acceleration is a self-reinforcing temporal structure that shapes how software organizations function, requiring careful analysis of which loops to speed up and which provide essential stability.
83
16
Article
Three Dots Labs·14w
The Distributed Monolith Trap (And How to Escape It)
Microservices solve organizational problems more than technical ones. Starting with a well-structured modular monolith is recommended over premature service splitting. Tight coupling persists even when services communicate over HTTP instead of function calls. Key warning signs include excessive inter-service calls and frequent cross-service changes. Event storming helps identify proper boundaries by mapping domain events and behaviors. Sometimes merging tightly coupled microservices back together is the right solution. Team structure should drive architecture decisions (reverse Conway maneuver), not the other way around.
78
3
17
Article
ITNEXT·14w
Clean Code Is a Guide, Not a Gospel: A Reflection on Pragmatic Software Architecture
Clean Code principles are valuable guidelines, not absolute rules. Architecture should serve business needs rather than dogmatic adherence to patterns. Over-engineering often stems from premature abstraction and complexity as status symbol. The best code prioritizes clarity and maintainability over cleverness. Start simple, evolve based on actual requirements, and apply principles thoughtfully rather than dogmatically. True engineering excellence means building understandable, maintainable systems that solve real problems, not demonstrating technical sophistication through unnecessary complexity.
75
5
18
Article
Nordic APIs·17w
What’s New in OpenAPI Specification v3.2.0?
OpenAPI 3.2.0 introduces incremental but significant improvements to the API specification standard. Key updates include first-class support for streaming media types (text/event-stream, application/jsonl) with schema definitions for individual stream items, hierarchical tag organization for better API navigation, support for extended HTTP methods including the QUERY method through additionalOperations, clarified path templating semantics for consistent routing across tools, clearer example semantics distinguishing data-level from serialized representations, and explicit OAuth 2.0 Device Authorization Flow support. These changes standardize patterns that previously required vendor extensions, making the specification more expressive for modern API designs while maintaining backward compatibility.
56
19
Article
The Next Web·17w
AI Skills
AI Skills represent a new conceptual layer above models and agents, functioning as reusable, procedural units that transform user intent into concrete execution. While models provide raw intelligence and agents coordinate tasks, Skills encode domain-specific expertise and workflows to deliver actual business outcomes. This modular, product-oriented approach scales better than building custom agents for every task, positioning Skills as the competitive differentiator as AI infrastructure commoditizes.
54
3
20
Article
Ramp Engineering·17w
Why We Built Our Own Background Agent
Ramp built Inspect, an internal background coding agent that writes and verifies code autonomously. Running in sandboxed VMs with full development environments, Inspect integrates with their entire tooling stack (Sentry, Datadog, GitHub, Slack) and supports multiple frontier models. The system achieves ~30% of all merged pull requests through fast session startup, unlimited concurrency, and multiplayer collaboration. The article provides a detailed technical specification for replicating their architecture, covering execution environments using Modal sandboxes, OpenCode agent integration, Cloudflare Durable Objects for state management, and client implementations including Slack bots, web interfaces, and Chrome extensions for visual React editing.
51
21
Article
UsmanCode·15w
I got tired of architectural advice that ignores trade-offs
A developer shares their frustration with architecture content that presents solutions without explaining trade-offs or constraints. They've created a public architecture notebook documenting architectural decisions, alternatives, trade-offs in .NET systems, and small runnable proofs. The repository emphasizes pragmatic, opinionated guidance that acknowledges real-world compromises and is open to revision based on experience.
48
9
22
Article
Advanced Web Machinery·18w
I'm changing my mind about serverless
Serverless architectures may no longer be the default choice for most applications. Modern dedicated servers offer massive capacity (192 cores, 3TB RAM) at reasonable costs (~$5k/month), eliminating traditional concerns about elasticity and scale ceilings. For most services, a single powerful server or primary-secondary setup provides sufficient reliability without the complexity of distributed systems. The trade-offs favor simpler architectures: no eventual consistency, easier debugging, local reproducibility, and fewer logical errors. Tools like NixOS enable infrastructure-as-code rigor while maintaining simplicity. Serverless remains valuable for bounded, infrequently-changing workloads, but actively-developed products may benefit from exploring single-server alternatives.
46
5
23
Article
Faun·15w
Beyond the Monolith: The Rise of the AI Microservices Architecture
LLM applications are evolving from monolithic architectures to microservices-based systems using agentic orchestration. This architectural pattern uses LangGraph as a central state machine to orchestrate independent, remote agents via HTTP calls, with semantic routing replacing brittle keyword matching. The hub-and-spoke model separates concerns: LangGraph maintains conversation state and makes decisions, semantic routing understands user intent, and specialized agents operate as independent HTTP services. This approach enables tech-agnostic development, independent scaling of components, fault tolerance, and better context management compared to traditional linear chains.
42
24
Article
Frederick's delirious rantings·17w
Bring back opinionated architecture
Enterprise architects often hide behind "it depends" and over-engineer for hypothetical future scenarios, creating unnecessary complexity and maintenance burden. Drawing from the YAGNI principle in software development, architects should make opinionated decisions based on current business needs rather than building multiple options "just in case." Technology can be made swappable, but organizations rarely are—the real cost lies in training, processes, and organizational change, not technical implementation. Making clear architectural choices and building simply for today's requirements leads to lower costs, faster delivery, and systems that actually serve the business.
38
2
25
Article
ploeh blog·16w
Filtering as domain logic
Complex database filtering logic can be split between server and client to balance performance and correctness. Keep simple, coarse-grained filtering in SQL queries for performance, while implementing precise filtering logic in the domain model where it's easier to test and maintain. This separation of concerns makes the filtering logic more testable through unit tests rather than slow integration tests, strengthens domain model contracts, and can improve cache hit ratios. The domain model should tolerate wider datasets and filter them down, ensuring correctness even if the database query is slightly imprecise.
30

See all Architecture archives