{"id":"19e16ef3-fffa-427c-a3d0-17984c3f3cb0","arxiv_id":"1908.04101","paper_version":3,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A survey-based taxonomy of 20 microservices anti-patterns with perceived harmfulness ratings and solutions, based on interviews with 27 practitioners.","lead":"This chapter catalogs 20 microservices anti-patterns, derived from interviews with 27 practitioners, and groups them into technical and organizational categories. It is a practical reference for teams migrating from monoliths to microservices, though the harmfulness ratings reflect perception and need further validation.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 'most common' label is not supported by n=27 convenience-sampled interviewees; observed frequencies have wide overlapping confidence intervals.","rationale":"I read the chapter as an empirical taxonomy-building study: 27 practitioner interviews, open and selective coding, inter-rater agreement, and a map onto prior grey literature. The descriptive catalog is a plausible contribution, and the authors acknowledge threats to validity. The reader's CONDITIONAL verdict hinges on sample representativeness; I agree that this is the central load-bearing assumption. I would sharpen it: even granting representativeness, the reported point frequencies (e.g., 2/27 = 7%) are too imprecise to support the 'most common' ordering; a Wilson confidence interval analysis would show broad overlap. The taxonomy itself need not be rejected, but the generalizing claim should be moderated and ideally re-tested on a larger, stratified sample. Therefore the verdict remains CONDITIONAL.","tokens_in":10659,"tokens_out":11849,"duration_ms":110227,"concrete_test":"Re-analyze Table 1.1 by computing exact binomial 95% confidence intervals (Wilson) for each 'Answers # / 27' proportion. If the intervals for the top four anti-patterns overlap with those of lower-ranked anti-patterns, the 'most common' ordering is not supported by the data; if they are separated and the intervals are narrow enough, the concern is resolved. Optionally, supplement with a saturation curve of unique anti-patterns versus interview order to test completeness.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim, stated in the abstract and in the reader's formulation, is that the catalog lists 'the most common' microservices anti-patterns. The data behind that claim are 27 face-to-face interviews with volunteers recruited from attendees of two practitioner conferences (O'Reilly Software Architecture Conference in London and the DevOps conference in Helsinki), described in Section 1.2.2. There is no saturation analysis, no confidence interval, and no comparison with a broader population. Table 1.1 shows several anti-patterns with only 2/27 (7%) mentions, e.g., No DevOps Tools, Non-homogeneous adoption, and Focus on Latest Technologies. With n=27, the 95% Wilson interval for a 37% observed proportion (e.g., Hardcoded Endpoints) is roughly 19-58%, and for a 7% proportion it is roughly 1-24%; these intervals overlap almost completely, so even the ordering by frequency is not statistically meaningful. If the sample is skewed toward DevOps/architecture conference attendees, the frequency estimates and the 'most common' label are even less secure. This does not invalidate the descriptive taxonomy, but it is the load-bearing assumption for the generalizing claim.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The chapter reports an empirical study in which 27 practitioners, recruited at two European practitioner conferences, were interviewed with a semi-structured protocol combining open questions and closed Likert-scale rankings. Using open and selective coding, the authors derive a taxonomy of 20 microservices anti-patterns split into organizational (team-oriented and technology/tool-oriented) and technical (internal and communication) groups, and for each anti-pattern they give a description, the problem it causes, and the solution adopted by interviewees. Four anti-patterns are presented as new: Local Logging, Lack of Monitoring, Lack of Microservice Skeleton, and No DevOps Tools. The chapter claims the catalogue lists the most common microservices anti-patterns and offers five lessons learned.","tokens_in":10897,"tokens_out":10414,"duration_ms":88904,"significance":"The main value of the paper is as a descriptive, practitioner-grounded catalogue: the qualitative method is appropriate, the two-stage interview design (open questions before closed ranking) reduces anchoring, inter-rater agreement reached 100% after discussion, and the authors are explicit that harmfulness ratings reflect perception only. The new anti-patterns, especially Local Logging and Lack of Microservice Skeleton, are plausible additions to the literature. I do not see a circularity problem: the taxonomy was generated from interview responses and could have produced different categories. The main limitation is that the sample is small, self-selected, and drawn from two events, so the paper's generalizing 'most common' wording is stronger than the evidence supports.","major_comments":[{"comment":"The claim that the catalogue lists 'the most common microservices anti-patterns' is not supported by the study design or the reported frequencies. The 27 interviewees were volunteers recruited from attendees of two practitioner conferences, and Table 1.1 shows counts as low as 2/27 (e.g., No DevOps Tools, Non-homogeneous adoption). With n=27, the 95% Wilson confidence intervals for the observed proportions overlap widely (e.g., roughly 22-56% for 10/27 and roughly 2-23% for 2/27), so even the ordering by frequency is not statistically meaningful. The paper should add a saturation analysis if it wants to claim completeness, and should either soften the 'most common' wording to 'reported by our interviewees' or substantially strengthen the sampling and statistical support.","section":"Abstract, §1.2.2, Table 1.1"},{"comment":"The paper states that harmfulness was analyzed with medians, but Table 1.1 reports values such as 6.05 for API Versioning and Shared Persistence, 3.05 for Lack of Microservice Skeleton, and 2.05 for Focus on Latest Technologies. On an integer 0-10 Likert scale, medians can only be integers or half-integers; these decimal values are impossible. The authors either computed means (contradicting their stated method) or the table contains typographical errors. Please correct this and report the actual medians.","section":"Table 1.1, §1.2.3"},{"comment":"The abstract says the catalogue 'is based on the experience summarized by different practitioners we interviewed,' but Table 1.1 and Figure 1.1 include anti-patterns with zero interviewee mentions (e.g., Timeout, Pride, Sloth, Magic Pixie Dust), which are carried over from the non-peer-reviewed literature. The paper should state explicitly which anti-patterns are empirically supported by the current interviews and which are literature-derived, and the abstract should be adjusted so it does not overstate the interview-based grounding.","section":"Abstract, §1.3, Fig. 1.1"}],"minor_comments":[{"comment":"The proposed solution 'accept the redundancy to increase dependency among teams' appears to be a typo; accepting redundancy should decrease inter-team dependency. Please correct.","section":"Table 1.3, Shared Libraries"},{"comment":"The paper says pairwise inter-rater reliability was measured, but no agreement statistic (e.g., Cohen's kappa) or raw values are reported; please report the measure.","section":"§1.2.3"},{"comment":"The statement 'No noticeable differences emerged among different roles or domains' is given without any supporting test or descriptive breakdown; with n=27, such a claim should be clearly labeled as an informal observation.","section":"§1.3"},{"comment":"The phrase 'we selected a relatively large set of participants' is misleading for n=27; please replace it with a more neutral description such as 'we selected 27 participants.'","section":"§1.3"},{"comment":"The citation [15] for 'refinement of the cycles according to their shape' appears to point to Pahl and Jamshidi's systematic mapping study, which does not obviously cover this topic; please verify the citation.","section":"Table 1.3, Cyclic Dependency"}],"recommendation":"major_revision","confidential_remarks":"I recommend major revision rather than rejection. The taxonomy is a useful qualitative contribution, and the main problems are overclaimed generality, an inconsistency in the reported harmfulness statistics, and an overstatement in the abstract about the interview-based grounding. The authors should be asked to correct the median values or the statistical description, add a clear limitations statement about the convenience sample, and adjust the abstract's 'most common' wording. I do not see a circularity problem with the taxonomy derivation."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThis is a decent, honest piece of qualitative cataloging. The authors interviewed 27 practitioners at two conferences, coded the answers with inter-rater agreement, and produced a taxonomy of 20 microservices anti-patterns, including four not in the existing practitioner lists (Local Logging, Lack of Monitoring, Lack of Microservice Skeleton, No DevOps Tools). The harmfulness ratings, though subjective, give a rough sense of what practitioners worry about. If you work on microservices migration or maintainability, this is a useful checklist.\n\nWhat it is not is a statistically grounded ranking. The stress-test note is correct: with n=27, the observed frequencies have wide overlapping confidence intervals. A pattern 'mentioned by 37% of interviewees' is not distinguishable from one at 7%. The phrase 'most common' in the abstract and Section 1.1 overclaims. The paper would be better if it said 'frequently reported in our sample' and left generality to future work. The authors do acknowledge the perception-based nature of harmfulness in the conclusion, and they list threats to validity, but they do not address the sample-size problem for their frequency ordering.\n\nThe method itself is appropriate for a descriptive taxonomy. Open and selective coding with two independent coders and 100% final agreement is standard. They also tried to reduce bias by asking open questions before presenting the practitioner list (Table 1.7). The relationship to their own previous survey [7] is somewhat tangled — this extends and reuses the earlier instrument — but the core claim is not circular: the data could have produced different categories, and the four new patterns came from the interviews.\n\nSoft spots, in order: (1) the 'most common' framing, which should be moderated; (2) no saturation analysis or comparison with a broader population; (3) the convenience sample from two DevOps/architecture events, which likely skews toward certain industries and maturity levels; (4) no replication package, so others cannot re-run the coding. None of these fatally undermine the descriptive catalog, but they cap the strength of the claims.\n\nVerdict: worth engaging with. It deserves a proper peer review, not a desk reject. A serious referee should ask for a more cautious generalization framing and either the interview instrument plus anonymized responses or a clear statement that the data are not sharable. I would cite it if I were writing about microservices smells, and I would bring it to a reading group on empirical SE methods, mainly as an example of a useful taxonomy with a small-sample generality problem.\n\nRecommendation: accept the paper as a worthwhile empirical contribution, but only after revision that brings the claims in line with the evidence.","headline":"A useful, well-scoped taxonomy of microservices anti-patterns, seriously limited by the 'most common' framing that outruns an n=27 convenience sample.","tokens_in":11401,"tokens_out":1988,"would_cite":true,"duration_ms":20003,"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 catalogues 20 microservices anti-patterns, grouped into technical and organizational categories, from interviews with 27 practitioners, and ranks their perceived harmfulness.","keywords":["microservices","anti-patterns","taxonomy","practitioner interviews","empirical software engineering","software architecture","organizational anti-patterns","harmfulness ranking"],"falsifier":"Re-run the same interview protocol with a larger, demographically broader sample drawn from different industries and company sizes, and check whether the same 20 anti-patterns recur with comparable harmfulness medians; if major new anti-patterns appear or the harmfulness order flips, the claim that this is the taxonomy of the most common microservices anti-patterns fails.","tokens_in":10478,"feed_emoji":"🐛","tokens_out":7358,"duration_ms":65625,"temperature":0.7,"pith_summary":"This chapter claims that the recurring mistakes teams make when building or migrating to microservices can be collected into a taxonomy of 20 anti-patterns, ranked by how harmful practitioners say they are. The taxonomy is built from interviews with 27 experienced developers at two practitioner conferences, extends an earlier survey, and is split into technical anti-patterns (internal and communication) and organizational ones (team-oriented and technology/tool-oriented). Four entries are new to the literature: Local Logging, Lack of Monitoring, Lack of Microservice Skeleton, and No DevOps Tools. A reader should care because the catalog turns scattered anecdotal lessons into a checklist that teams can consult before and during migration, and it gives researchers a concrete set of claims to test.","feed_headline":"Twenty microservices anti-patterns, ranked by harm, from 27 interviews","feed_subtitle":"Four of the entries are new, and each anti-pattern comes with the solution practitioners used to recover.","key_machinery":"The carrying mechanism is the anti-pattern taxonomy itself: a two-branch classification that separates technical anti-patterns (internal faults such as Megaservice and Inappropriate Service Intimacy, and communication faults such as Cyclic Dependency and No API-Gateway) from organizational anti-patterns (team-oriented such as Common Ownership, and technology/tool-oriented such as Too Many Technologies and No DevOps Tools). The taxonomy is derived by open and selective coding of interview answers, with each entry pairing a description and detection heuristic with the problem it causes and the solution the practitioners adopted. That structure lets the catalog serve both as a warning list and as a recovery manual.","core_discovery":"The paper's central claim is that the most common microservices problems are not only architectural mistakes but also organizational ones, and that both kinds can be named, grouped, and ranked. Based on practitioners' reports, the authors identify 20 anti-patterns, classify them into technical and organizational categories, and report both the median perceived harmfulness on a 0–10 scale and the solutions practitioners used to recover. Wrong Cuts, Hardcoded Endpoints, Cyclic Dependency, and Shared Persistence rank as the most harmful; the four newly named anti-patterns reflect the growing importance of operations concerns. The catalog also lists anti-patterns proposed in practitioner literature that none of the interviewees had experienced, so the taxonomy distinguishes observed from merely anticipated pitfalls.","pith_inferences":["Beyond the paper: because the sample was 27 practitioners, the list is likely a lower bound on the real set of common anti-patterns, so absence from this catalog should not be read as evidence that a practice is safe.","Beyond the paper: the sharp split between organizational and technical anti-patterns suggests a diagnostic order, namely that fixing team structure and tooling first may prevent several technical anti-patterns from arising.","Beyond the paper: a testable extension is to convert each detected anti-pattern into a measurable architecture metric, such as number of inter-service cycles or absence of a service-discovery component, and check whether higher values predict the maintenance failures the interviewees described.","Beyond the paper: since all four new anti-patterns are operational rather than architectural, the taxonomy hints that the next wave of microservices failures may be concentrated in observable system behavior rather than service decomposition."],"forward_implications":["Teams can use the catalog as a pre-migration checklist to spot conditions that produced the reported problems, and adopt the listed solutions (service discovery, API gateways, distributed logging, per-service databases or schemas) before the pain appears.","The harmfulness medians give researchers a first ranking to validate against objective measures of defects, maintenance cost, or delivery speed.","The four new operations-oriented anti-patterns imply that monitoring and DevOps tooling are now part of microservices competence, not optional infrastructure.","The taxonomy can structure future empirical work: each entry names a detection heuristic, such as cycles in call graphs, shared database access, or local log storage, that later studies can turn into automated detectors."],"supporting_citations":[{"why":"Supplies the earlier survey, questionnaire, and baseline bad-practice list that this study replicates and extends.","marker":"[6]"},{"why":"Provides the open and selective coding procedure used to derive anti-pattern categories from interview answers.","marker":"[3]"},{"why":"Contributes three practitioner pitfalls (Timeout, I Was Taught to Share, Static Contract) folded into the catalog.","marker":"[8]"},{"why":"Adds Hardcoded IPs and Ports and API versioning issues to the candidate list.","marker":"[10]"},{"why":"Contributes Megaservice, Shared Persistence, and Leak of Service Abstraction as candidate anti-patterns.","marker":"[9]"},{"why":"Supplies the data-ownership framing of the Shared Persistence anti-pattern.","marker":"[11]"},{"why":"Contributes the No API-Gateway anti-pattern.","marker":"[12]"},{"why":"Supplies several of the seven deadly sins of microservices that appear in the taxonomy.","marker":"[13]"},{"why":"Supplies the organizational adoption anti-patterns, such as legacy organization and scattershot adoption, that motivate the organizational branch.","marker":"[22]"}],"fun_headline_variants":["Microservices anti-patterns: 20 pitfalls, 4 new, harm-ranked","New taxonomy ranks 20 microservices anti-patterns by harm","Organizational and technical traps: 20 microservices anti-patterns","From interviews: 20 microservices anti-patterns, with fixes","Catalog of 20 microservices anti-patterns, including 4 new ones"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole taxonomy rests on the assumption that the 27 practitioners interviewed at two conferences are representative enough of microservices practice that their experienced problems can be called the most common ones.","fun_headline_variants_meta":{"raw":{"variants":["Microservices anti-patterns: 20 pitfalls, 4 new, harm-ranked","New taxonomy ranks 20 microservices anti-patterns by harm","Organizational and technical traps: 20 microservices anti-patterns","From interviews: 20 microservices anti-patterns, with fixes","Catalog of 20 microservices anti-patterns, including 4 new ones"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000184,"raw_usage":{"total_tokens":1278,"prompt_tokens":862,"completion_tokens":416,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":478,"completion_tokens_details":{"reasoning_tokens":316}},"tokens_in":478,"tokens_out":416,"duration_ms":4092,"temperature":1.0,"reasoning_tokens":316,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T13:50:55.131567+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Re-run the same interview protocol with a larger, demographically broader sample drawn from different industries and company sizes, and check whether the same 20 anti-patterns recur with comparable harmfulness medians; if major new anti-patterns appear or the harmfulness order flips, the claim that this is the taxonomy of the most common microservices anti-patterns fails.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Adds Hardcoded IPs and Ports and API versioning issues to the candidate list."},{"cited_title":"V. Alagarasan","cited_arxiv_id":null,"evidence_quote":"Contributes the No API-Gateway anti-pattern."},{"cited_title":"Bryant (SpectoLabs)","cited_arxiv_id":null,"evidence_quote":"Supplies several of the seven deadly sins of microservices that appear in the taxonomy."}],"review_version":1}