Literature review
AuraScore 81/100

Microservices Decoupling and Modular Monolith Synthesis Framework

Synthesizes empirical software engineering literature to evaluate trade-offs between modular monoliths and distributed microservices architectures.

Use this template when transitioning enterprise software architectures or evaluating refactoring paradigms backed by peer-reviewed empirical studies. It provides an objective decision-making framework tailored to specific throughput and organizational constraints.

Template

Role: Principal Enterprise Systems Architect and Empirical Software Research Lead

Context

  • Target System Scale: {{target_system_scale}}
  • Current Architectural Bottlenecks: {{current_bottlenecks}}
  • Literature Corpus Focus: {{literature_corpus_focus}}
  • Team Structure & Topology: {{organizational_topology}}
  • Runtime Latency Tolerance: {{latency_tolerance}}
  • Compliance and Regulatory Boundaries: {{compliance_boundary}}

Task

Synthesize the peer-reviewed empirical literature on microservices versus modular monolith architectures into an actionable technical framework that evaluates migration feasibility, operational overhead, and distributed failure modes for {{target_system_scale}}.

Method

  1. Extract empirical findings from {{literature_corpus_focus}} addressing bounded context separation, network serialization overhead, and data consistency models.
  2. Correlate published findings on developer cognitive load against {{organizational_topology}} and domain boundary complexity.
  3. Map identified architectural trade-offs to the system's specific {{current_bottlenecks}} and {{latency_tolerance}} requirements.
  4. Synthesize state-of-the-art consensus on distributed transaction patterns (e.g., Saga, Two-Phase Commit) versus monolithic transactional integrity within {{compliance_boundary}}.
  5. Categorize empirical failure archetypes documented in the literature regarding partial network failures and cascading degradations.
  6. Formulate a multi-criteria scoring matrix assessing maintainability, deployment velocity, observability cost, and infrastructure overhead.
  7. Construct a phased decision tree that prescribes architectural boundaries based on empirical thresholds.

Constraints

  • MUST cite empirical metrics (e.g., DORA metrics, MTTR, latency percentiles) documented in software engineering literature.
  • MUST NOT recommend distributed patterns without explicit mitigation strategies for data partitioning and distributed tracing.
  • Every architectural recommendation must map directly back to findings derived from {{literature_corpus_focus}}.
  • Theoretical claims must be balanced against operational realities defined by {{organizational_topology}}.

Output format

  • Section 1: Executive Empirical Synthesis (max 300 words)
  • Section 2: Architectural Trade-off Taxonomy (structured comparative table across 5 dimensions)
  • Section 3: Empirical Decision Matrix & Scoring Rubric
  • Section 4: Boundary Transition Decision Tree (ordered conditional rules)
  • Section 5: Risk & Failure Mode Inventory (max 4 critical risk profiles)

Self-review

  • Verify that all operational trade-offs directly address {{current_bottlenecks}}.
  • Ensure the scoring matrix includes quantitative criteria derived from peer-reviewed benchmarks.
  • Confirm that no ungrounded industry hype is presented as empirical evidence.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

research-analysis
research-literature
technology-software
software-architecture
systematic-review
microservices