software architecture

Bilingual

What Even Are Microservices?
2 months ago
- Microservices are difficult to define technically; their boundaries are organizational rather than based on code size or responsibilities.
- The main problem microservices solve is organizational scaling, allowing teams to work independently, not technical issues like slow builds or tests.
- Microservices trade centralization for autonomy, introducing network communication costs, runtime failures, and loss of easy static analysis.
- Team communication overhead increases as API changes become negotiations requiring versioning and coordinated database changes.
- Microservices should be chosen for organizational scaling needs, not as a purely technical solution.
How to write complex software
2 months ago
- Start by writing toy driver programs to discover physical constraints of the solution space
- Begin implementation at the top of the stack (UI or API) and work downward
- Implement software in layers where each layer peels off minimal logic and delegates complexity
- When coding a layer, define the next layer's API as the perfect domain-specific language for the current layer
- Stub out the lower layer as you code the current layer, then recursively implement it for real
- Only use mockable abstract interfaces for IO parts; all else should be concrete
- This method enables early semi-working software and natural delegation among engineers
- If a layer's API is impossible to implement, backtrack and redesign the layer above
Every Man a Microservice
2 months ago
- Conway's law is inverted: a system's design shapes the organization's communication structure, not the other way around.
- The ideal system design is composed of person-sized services, each with a codebase of tens of thousands of lines that a single developer can fully comprehend.
- Person-sized services enable offline mulling, fast consensus on improvements, fewer outages, higher quality, politically manageable architectural changes, and faster engineer development.
- Traditional team-owned services lead to purely accretive changes, fear of deep refactors, and political resistance to deprecation.
- Bus factor risk is mitigated by senior engineers who have context on multiple services and can step in; juniors are mentored and grow into owners.
- Such an organization requires few managers and relies on senior technical lieutenants for visibility, as most systems need only a few dozen services.
How to be useful as a software architect
2 months ago
- Software architects must balance improving future code with maintaining current business speed.
- Common architect failure modes include writing ignored documentation, enforcing rigid rules, or burning out by doing all the cleanup work.
- Effective architects build systems that enable fast, safe contributions from all team members.
- Code review and system design review are key, but they should not become bottlenecks; automation and culture can help scale these processes.
- A strong culture includes making developers own the consequences of their work, explaining reasoning to spread knowledge, and using memorable analogies.
- Feedback loops such as tests, strong typing, and observability are essential to manage complexity and catch mistakes early.
- Automation, including linters, formatters, and AI-driven code review bots, reduces repetitive debates and scales architectural guidance.
- Gardening the system involves both technical and human elements, with culture and automation supporting sustainable codebase improvement.
MetaPatterns
2 months ago
- The pattern language of software architecture emphasizes that architectural patterns are interrelated and no pattern exists in isolation.
- Architectural Metapatterns generalizes hundreds of patterns into a few classes, applicable to both local and distributed systems.
- The online book version, available on GitHub and Leanpub, provides a tree-like hierarchy of architectural patterns, grouping them into less than 20 classes.
- The book includes supplementary topics on complexity, orchestration, choreography, and shared data integration, along with system evolution examples.
- The content is AI-free, 440 pages long, and uses intuitive NoUML diagrams.
Comparing Fable and 10 other LLMs on refactoring a LangGraph god node
3 months ago
- The article describes an experiment where 11 LLMs (including Fable-5, GPT models, and others) were tasked with proposing refactoring solutions for a 'god node' in a LangGraph agent, followed by cross-evaluations of each other's proposals.
- The 'god node' (plan node) contained about 350 lines of hidden logic, making the graph hard to debug, test, and change. The goal was to lift this logic to the graph level for clarity.
- In stage one, each model generated a proposal to split the plan node. Proposals varied in granularity, from balanced pipelines (e.g., Fable-5's 5-stage split) to more coarse or detailed approaches.
- In stage two, models evaluated all proposals. Reviews differed in thoroughness: Fable-5's review was meticulous with bug findings, while others like Gemini-3.1-pro were minimalistic.
- Stage three involved comparing proposals and reviews using methods like average scores, thesis analysis, and meta-evaluations to determine the best proposal and analyst.
- The best proposal by average score was Fable-5's, followed by GPT-5.4 and GPT-5.5. For evaluators, GPT-5.5 was a top predictor of consensus, while Fable-5 and GPT-5.5 were highly rated in meta-analyses.
- Key takeaways: For generating architecture, Fable or GPT models are recommended; for evaluation, GPT-5.5 or Fable-5 are good, but human oversight is still needed as models make errors.

software architecture

What Even Are Microservices?

How to write complex software

Every Man a Microservice

How to be useful as a software architect

MetaPatterns

Comparing Fable and 10 other LLMs on refactoring a LangGraph god node