{"id":"86e61391-f470-41f2-ab79-cde0c598d442","arxiv_id":"1908.08513","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"A four-metric framework (coupling, class count, duplication, external call frequency) is defined to compare microservice decomposition options and combined with process-mining-based decomposition.","lead":"This paper proposes a measurement framework with four metrics to compare different ways of splitting a monolithic software system into microservices, and it extends an earlier process-mining decomposition approach. A smart generalist reader might use it to understand how runtime logs can guide and evaluate microservice migration decisions.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"FEC and CBM normalize external-call counts by number of classes, so splitting or duplicating classes changes scores without changing call costs; this undermines the claimed objective comparison.","rationale":"I focused on the measurement framework because that is where the abstract's strongest claim lives. The reader's trace-completeness assumption is real: without full traces all dynamic metrics are ungrounded. But the paper itself states that assumption explicitly, and even under perfect traces the FEC and CBM definitions have a serious validity problem: they are normalized by the number of classes, which is itself a variable the decomposition controls and which CLA measures. This creates an internal inconsistency where a purely syntactic change (splitting a class) improves the scores without improving the architecture. I therefore partially agree with the reader: the trace assumption is a prerequisite, but the more load-bearing soft spot is the construct validity of the metrics. Because this is a proposal paper and the flaw is fixable (use absolute counts or a justified normalization), I keep the verdict at CONDITIONAL; specifically, the condition should include redefining or re-validating FEC/CBM before the framework is used to compare options. I do not see grounds to reject outright, and the authors do acknowledge validation is future work in Section 7.","tokens_in":97,"tokens_out":8513,"duration_ms":202585,"concrete_test":"Create a synthetic log with one microservice containing one class that makes 10 external calls; compute FEC and CBM. Split that class into two classes within the same microservice, preserving the same 10 external call instances (5 each), and recompute. If FEC drops from 10 to 5 and CBM drops while absolute external-call cost is unchanged, the metrics fail the interpretation given in §3.4. Also recompute Table 2 row 0 using the paper's 1000x factor: if the load column does not equal 100*1000 + 1150, the illustrative calculation needs correction.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Even if the Section 2.4 trace-completeness assumption is granted, the central claim that the four metrics objectively compare decompositions is not safe. FECMS_j = Number of Call Instances / Number of Classes in the Microservice (§3.4) and CBMMS_j = Number of External Links / Number of Classes in the Microservice (§3.1) both use the number of classes as denominator. Class boundaries are a free parameter of the decomposition: a team can split one class into two or duplicate a class (an option §3.3 explicitly considers) and thereby lower both FEC and CBM while leaving the absolute number and cost of inter-service calls unchanged. The result is that a decomposition can look better on the metrics for reasons unrelated to coupling, cohesion, or call cost, so the 'objective' ranking is partly an artifact of class granularity. The paper's own example is internally inconsistent: in Table 2, split 0 has internal calls 1150, external calls 100, and an external call assumed 1000x heavier, but the listed load is 101550 instead of 100*1000 + 1150 = 101150. The framework may be salvageable, but the metric definitions need to be tied to absolute call counts or otherwise made invariant to irrelevant class splits.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper proposes a measurement framework for evaluating microservice decompositions, using four metrics (CBM, CLA, DUP, FEC) derived from runtime execution traces, and presents it as an extension of the authors' prior process-mining decomposition framework. The framework is intended to support objective comparison of decomposition options and continuous evaluation of architectural erosion, and the paper illustrates the metrics on a hypothetical example with calculated values in Table 2. No empirical validation is reported; the authors explicitly state that validation is future work.","tokens_in":10950,"tokens_out":3748,"duration_ms":33673,"significance":"The intended contribution is a repeatable, quantitative way to compare decomposition alternatives using dynamic call data rather than expert judgment alone. The transparency and simplicity of the proposed formulas are strengths, as is the explicit integration with an existing trace-based decomposition process. However, the current formulation has a load-bearing granularity sensitivity in two of the four metrics, and the objectivity claim is unsupported by empirical evidence in this manuscript. If robust definitions and validation are provided, the framework could be genuinely useful to migration practitioners.","major_comments":[{"comment":"Both CBM and FEC are normalized by the number of classes in the microservice. This makes the metrics depend on class granularity: splitting or duplicating a class can change the denominator and thus the metric value without changing the actual number or cost of external calls. Since decomposition options may already differ in how classes are grouped or duplicated (e.g., §3.3 explicitly considers duplication), the claimed objective comparability is not guaranteed. Please either normalize by absolute call/link counts and path lengths, or provide a formal justification for why class count is an appropriate denominator and why the metric is invariant under class splits.","section":"§3.1 and §3.4, Eqs. (1) and (2)"},{"comment":"The reported load value for split 0 is inconsistent with the stated assumption. With 100 external calls, 1150 internal calls, and an external call 1000 times heavier than an internal call, the load should be 100*1000 + 1150 = 101150, not 101550 as listed. This arithmetic discrepancy must be corrected, and the example should be recomputed to ensure all FEC and load values follow from the formulas.","section":"Table 2 (Section 3.4)"},{"comment":"The central claim that the framework \"helps to decrease subjectivity\" is not supported by any empirical study in this paper; the only example is hypothetical, and the authors explicitly defer validation to future work. At minimum, an evaluation with real traces (even a small case study) or a demonstration on a known open-source system is needed to support the claim about usefulness for companies and erosion detection.","section":"Sections 5 and 7"}],"minor_comments":[{"comment":"\"very difficult and complex tasks\" should be \"task\"; the sentence should be grammatically revised.","section":"Section 1"},{"comment":"\"two big\" should be \"too big\".","section":"Section 3.2"},{"comment":"\"reported buy Khadka\" should be \"reported by Khadka\".","section":"Section 6"},{"comment":"\"identity different\" should be \"identify different\".","section":"Section 4.4"},{"comment":"The definition of \"Number of External Links\" is ambiguous; please specify whether it counts distinct external services or distinct call paths, and how this interacts with the FEC measure.","section":"Section 3.1"},{"comment":"Figures 3 and 4 are referenced but their content is not fully described in the text; please clarify what the reader should observe in Figure 4, especially the duplication scenario.","section":"Figures 3 and 4"}],"recommendation":"major_revision","confidential_remarks":"The paper relies substantially on the authors' own prior framework [36] for validity, and the novelty of the new measurement framework is modest; the editor may want to consider whether the venue expects empirical validation for claimed practical benefits. No other concerns."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a short proposal paper that packages four simple metrics into a measurement framework for comparing microservice decompositions. It reads honestly – the authors state up front that validation is future work. The genuinely new piece is the measurement layer; the decomposition process is from their earlier work [36].\n\nWhat it does well: the paper is clearly structured, the metrics are described precisely enough to implement, and the idea of using runtime traces rather than static analysis for coupling is sensible. The four metrics (coupling, class count, duplication, external-call frequency) are individually standard, but the combination gives practitioners a concrete checklist. The worked example, apart from one arithmetic slip, is easy to follow.\n\nThe soft spots, in proportion. First, the central claim – that this reduces subjectivity in choosing between decomposition options – is not backed by any data here. That is fine for a proposal, but it means the paper's contribution is a speculative framework, not a validated method. Second, the stress-test concern is real: FEC and CBM divide by the number of classes, so splitting or duplicating classes changes the scores without changing the actual call costs. The paper itself lists duplication as a legitimate decomposition option (Section 3.3), which makes the normalization weakness directly relevant. As written, the metrics can reward a decomposition that looks better on paper but is not actually cheaper or more cohesive. This should be fixed by tying the metrics to absolute call counts or making them invariant to class granularity. Third, the trace-completeness assumption (Section 2.4) is strong; if logs are incomplete, all four metrics lose their grounding. The authors acknowledge this, but it is a hard practical constraint. Finally, there is a minor arithmetic error in Table 2: split 0's load should be 101150 (100 external × 1000 + 1150 internal), not 101550. The table formatting also looks off in the last row.\n\nWho this is for: someone doing a literature survey on microservice decomposition or looking for a starting point for metric design. It is not a paper with empirical results, so it should not be treated as evidence that the framework works. It deserves a serious referee because the idea is plausible and the field needs more systematic comparison methods; the referee should push for the normalization fix and for any available data, even preliminary.\n\nRecommendation: send it to peer review, but expect that the metric definitions need revision and the validation is still outstanding.","headline":"A clear, honest proposal for comparing microservice decompositions with four simple metrics, but the metrics are unvalidated and the ones normalizing by class count are gameable by class splitting.","tokens_in":11451,"tokens_out":2420,"would_cite":false,"duration_ms":22979,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper proposes a four-metric measurement framework, computed from runtime execution traces, that lets software architects compare microservice decompositions objectively and monitor architectural erosion over time.","keywords":["microservices","decomposition","measurement framework","process mining","execution traces","coupling metric","architectural erosion","monolith migration"],"falsifier":"Take a monolith with complete execution traces, compute the four metrics for two decomposition options, and benchmark the production latency and maintenance cost of each; if the option with lower CBM and FEC performs consistently worse, the central claim that these metrics indicate decomposition quality would be falsified.","tokens_in":10521,"feed_emoji":"📏","tokens_out":6455,"duration_ms":57679,"temperature":0.7,"pith_summary":"Migrating a monolithic system to microservices usually comes down to an architect's manual judgment about where to slice the code. This paper argues that the choice can be made more objective through four metrics computed from runtime execution traces: coupling between microservices, number of classes per microservice, duplicated classes, and frequency of external calls. The same metrics also allow a company to track whether an existing microservice system is eroding as it evolves. The paper combines these measures with a process-mining decomposition framework that turns log files into candidate slicing options, so that options can be generated from actually executed call paths rather than from static dependency analysis alone.","feed_headline":"Four metrics turn microservice split decisions into numbers","feed_subtitle":"Execution-trace metrics for coupling, size, duplication, and call frequency reduce subjectivity in architecture decisions.","key_machinery":"The load-bearing object is the four-measure metric suite, computed from the call frequencies in log traces of the monolith (or of an existing microservice system). CBM follows the classic Coupling Between Objects idea, counting external links relative to class count; CLA is a size proxy that flags microservices that are too large or too small; DUP counts shared sub-paths that would force code duplication if placed in separate services; FEC divides the number of cross-service call instances by the class count, quantifying the performance cost of a split. The measures are fed by a decomposition pipeline: execution path analysis, frequency analysis, circular dependency removal, and identification of candidate slices, followed by metric-based ranking. What gives the machinery its force is that every number is grounded in observed runtime behavior rather than in static dependencies, so the comparison reflects the system as it actually runs.","core_discovery":"The central claim is that the quality of a microservice decomposition can be evaluated with repeatable, objective measures derived from complete execution logs. Four measures are defined: Coupling Between Microservice (CBM), the number of external links per class in each microservice; CLA, the number of classes per microservice; DUP, the number of classes that would need to be duplicated across microservices; and FEC, the number of call instances per class that cross service boundaries. Because external calls are computationally much heavier than internal calls, FEC captures the run-time cost of a split, while CBM captures its coupling. Applied to alternative decompositions of the same monolith, these measures support a numerical comparison that complements or challenges the architect's intuition; applied periodically to a running system, they reveal architectural erosion as the numbers drift. The paper does not claim to automate the decision: it presents measurements plus a six-step process that still leaves the final choice to the team.","pith_inferences":["With complete traces, the same four metrics could serve as a continuous-integration gate: a commit that increases FEC or CBM beyond a chosen threshold would automatically flag a quality regression.","The framework implicitly assumes a fixed relative cost of external versus internal calls; the example uses a 1000x weight, and if the true ratio varies by deployment, the ranking between decomposition options could change, so sensitivity analysis on this weight is a direct test of the framework's stability.","The metrics treat classes as the atomic unit; in languages or systems with different granularities, the approach should transfer if execution paths can be traced, suggesting applicability beyond Java-style object-oriented monoliths.","Because decomposition options are still identified manually in Step 4, the framework reduces subjectivity in comparing options but not in generating them; extending it with an algorithmic candidate generator would close that gap."],"forward_implications":["The framework works independently of how decompositions are generated, so any two candidate splits can be compared numerically.","Periodic reapplication to a live microservice system yields a historical record of metric drift, giving an early warning of architectural erosion.","The dynamic call frequencies highlight the most-used features, allowing teams to prioritize which slices to develop first.","If the approach matures, the metric-defined objective could be handed to an automated optimizer, such as a genetic algorithm, to propose decompositions that maximize the quality measures.","Metric conflicts, such as smaller services raising coupling and call frequency, remain a team judgment call, but the trade-offs become explicit and quantifiable."],"supporting_citations":[{"why":"Defines the CBM metric and the six-step decomposition process that this paper extends.","marker":"[36]"},{"why":"Supplies the working definition of microservices and the architectural goals of high cohesion and loose coupling.","marker":"[7]"},{"why":"Provides the Coupling Between Objects metric that the CBM coupling measure is adapted from.","marker":"[3]"},{"why":"Empirical evidence that low coupling and high cohesion relate to external quality, justifying the cohesion-coupling inversion.","marker":"[10]"},{"why":"Defines loose coupling for services, grounding the decoupling objective the metrics operationalize.","marker":"[19]"},{"why":"Demonstrates unobtrusive trace collection via Aspect-Oriented Programming, a method for obtaining the log data the framework requires.","marker":"[26]"},{"why":"Documents practitioner migration processes and the manual decomposition step, motivating the need for objective comparison.","marker":"[31]"},{"why":"Proposes function-splitting heuristics closest to this work; this paper distinguishes itself by adding quality measures and using dynamic traces.","marker":"[4]"},{"why":"Case study of legacy-to-SOA migration analyzing call paths, a comparative precedent for using call-path analysis in migration.","marker":"[12]"}],"fun_headline_variants":["Objectively compare microservice splits with four metrics","Four code metrics quantify microservice decomposition quality","Measure microservice splits: coupling, size, duplication, calls","Microservice decomposition scored by execution-trace metrics","Four metrics replace gut feeling in microservice split decisions"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The framework assumes complete end-to-end execution traces exist: every user action or external call must be traceable from its entry point through every internal method to the database and back, so if logs omit any part of the call path, the frequency analysis and all four metrics lose their grounding.","fun_headline_variants_meta":{"raw":{"variants":["Objectively compare microservice splits with four metrics","Four code metrics quantify microservice decomposition quality","Measure microservice splits: coupling, size, duplication, calls","Microservice decomposition scored by execution-trace metrics","Four metrics replace gut feeling in microservice split decisions"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000323,"raw_usage":{"total_tokens":1767,"prompt_tokens":853,"completion_tokens":914,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":469,"completion_tokens_details":{"reasoning_tokens":854}},"tokens_in":469,"tokens_out":914,"duration_ms":7137,"temperature":1.0,"reasoning_tokens":854,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T11:36:47.005913+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a monolith with complete execution traces, compute the four metrics for two decomposition options, and benchmark the production latency and maintenance cost of each; if the option with lower CBM and FEC performs consistently worse, the central claim that these metrics indicate decomposition quality would be falsified.","supporting_citations":[{"cited_title":"In: 9th International Conference on Cloud Computing and Services Science, CLOSER , 2019","cited_arxiv_id":null,"evidence_quote":"Defines the CBM metric and the six-step decomposition process that this paper extends."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the working definition of microservices and the architectural goals of high cohesion and loose coupling."},{"cited_title":"IEEE Trans","cited_arxiv_id":null,"evidence_quote":"Provides the Coupling Between Objects metric that the CBM coupling measure is adapted from."},{"cited_title":"Em- pirical Softw","cited_arxiv_id":null,"evidence_quote":"Empirical evidence that low coupling and high cohesion relate to external quality, justifying the cohesion-coupling inversion."},{"cited_title":"O’Reilly Media, Inc., 1st edn","cited_arxiv_id":null,"evidence_quote":"Defines loose coupling for services, grounding the decoupling objective the metrics operationalize."},{"cited_title":"In: International Workshop on Software Measurement (IWSM)","cited_arxiv_id":null,"evidence_quote":"Demonstrates unobtrusive trace collection via Aspect-Oriented Programming, a method for obtaining the log data the framework requires."},{"cited_title":"IEEE Cloud Computing 4(5), 22–32 (2017)","cited_arxiv_id":null,"evidence_quote":"Documents practitioner migration processes and the manual decomposition step, motivating the need for objective comparison."},{"cited_title":"In: Pahl, C., Vukovic, M., Yin, J., Yu, Q","cited_arxiv_id":null,"evidence_quote":"Proposes function-splitting heuristics closest to this work; this paper distinguishes itself by adding quality measures and using dynamic traces."},{"cited_title":"In: 2013 20th Working Conference on Reverse Engineering (WCRE)","cited_arxiv_id":null,"evidence_quote":"Case study of legacy-to-SOA migration analyzing call paths, a comparative precedent for using call-path analysis in migration."}],"review_version":1}