Microservices Anti Patterns: A Taxonomy

Claus Pahl; Davide Taibi; Valentina Lenarduzzi

REVIEW 3 major objections 5 minor 19 references

Microservices Anti Patterns: A Taxonomy

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper catalogues 20 microservices anti-patterns, grouped into technical and organizational categories, from interviews with 27 practitioners, and ranks their perceived harmfulness.

desk verdict A useful, well-scoped taxonomy of microservices anti-patterns, seriously limited by the 'most common' framing that outruns an n=27 convenience sample. read the letter →

arxiv 1908.04101 v3 pith:DRZPWODX submitted 2019-08-12 cs.SE

Davide Taibi , Valentina Lenarduzzi , Claus Pahl This is my paper · ORCID

classification cs.SE

keywords microservicesanti-patternstaxonomypractitionerinterviewsempiricalsoftwareengineeringarchitectureorganizationalharmfulnessranking

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

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.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague,

This 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.

What 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.

The 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.

Soft 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.

Verdict: 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.

Recommendation: accept the paper as a worthwhile empirical contribution, but only after revision that brings the claims in line with the evidence.

Referee Report

3 major / 5 minor

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.

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 (3)

[Abstract, §1.2.2, Table 1.1] 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.
[Table 1.1, §1.2.3] 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.
[Abstract, §1.3, Fig. 1.1] 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.

minor comments (5)

[Table 1.3, Shared Libraries] 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.
[§1.2.3] 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.
[§1.3] 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.
[§1.3] 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.'
[Table 1.3, Cyclic Dependency] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the taxonomy is interview-derived and the self-citations are independent empirical inputs, not load-bearing reductions.

full rationale

The claimed derivation is an empirical catalog: 27 semi-structured interviews, open and selective coding, and a taxonomy. The anti-patterns are not defined to equal the inputs by construction. The paper explicitly separated the open questions from the prompted list: "in order to avoid influencing the interviewees, we asked them to list their own bad practices, without providing them with a list of pitfalls previously identified by practitioners [6,9,10,11,12]" (Section 1.2.1). Four NEW anti-patterns (Local Logging, Lack of Monitoring, Lack of Microservice Skeleton, No DevOps Tools) emerged from those open answers, so the output was not forced by the pre-specified instrument. The reuse of the authors' earlier questionnaire [6] and the mapping to Table 1.7 are transparent replication and extension steps, not load-bearing self-citation: the frequencies in Table 1.1 are reported interview results, not predictions fitted from [6] or [7]. The cited prior works are empirical surveys, externally falsifiable, and do not by themselves entail the new taxonomy. The n=27 and wide-confidence-interval concern is a threat to the generalization of the "most common" wording, but it is a validity and correctness issue, not circularity. No equation or construction in the paper makes an output equal to an input by definition.

Assumptions & free parameters 0 free parameters · 3 assumptions · 4 invented entities

The taxonomy rests on the interview sample and on the coding process, not on a mathematical model. No free parameters are fit. The axioms listed are the trust assumptions: self-reports reflect real harm, the two-year experience cutoff is meaningful, and grounded-theory coding yields valid categories. The four new anti-patterns are introduced entities with no external validation.

assumptions (3)

domain assumption Self-reports by practitioners accurately describe the harms of the practices they discuss.
The entire catalogue rests on interview answers about which practices caused issues; no objective measurement or repository mining is used.
domain assumption Two years of microservices experience is sufficient to be an experienced developer.
Section 1.2.2 uses this cutoff to filter participants, but it is not validated.
domain assumption Open and selective coding produces categories that reflect the underlying phenomena rather than the coders' prior expectations.
The taxonomy is extracted via grounded-theory coding by two authors; inter-rater agreement is reported, but coding validity is assumed.

invented entities (4)

Local Logging
purpose: Anti-pattern where log files are stored inside each microservice container instead of a distributed logging system; added as a new entry.
Introduced based on interview responses (Table 1.2); no external measure or replication provides independent support.
Lack of Monitoring
purpose: Anti-pattern where no monitoring system checks service liveness and correctness; added as new.
Based on three interviewee reports (Table 1.1); no independent verification.
Lack of Microservice Skeleton
purpose: Anti-pattern where each team reimplements boilerplate for connecting to shared infrastructure; added as new.
Based on nine interviewee reports (Table 1.1); no independent verification.
No DevOps Tools
purpose: Anti-pattern where the company lacks CI/CD tooling and deploys manually; added as new.
Based on two interviewee reports (Table 1.1); no independent verification.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Microservices Anti Patterns: A Taxonomy." pith.science (2026). https://pith.science/paper/DRZPWODX

@misc{pith2026190804101,
  author       = {Pith},
  title        = {Pith review of: Microservices Anti Patterns: A Taxonomy},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DRZPWODX}},
  note         = {Machine review of arXiv:1908.04101}
}

read the original abstract

Several companies are re-architecting their monolithic information systems with microservices. However, many companies migrated without experience on microservices, mainly learning how to migrate from books or from practitioners' blogs. Because of the novelty of the topic, practitioners and consultancy are learning by doing how to migrate, thus facing several issues but also several benefits. In this chapter, we introduce a catalog and a taxonomy of the most common microservices anti-patterns in order to identify common problems. Our anti-pattern catalogue is based on the experience summarized by different practitioners we interviewed in the last three years. We identified a taxonomy of 20 anti-patterns, including organizational (team oriented and technology/tool oriented) anti-patterns and technical (internal and communication) anti-patterns. The results can be useful to practitioners to avoid experiencing the same difficult situations in the systems they develop. Moreover, researchers can benefit of this catalog and further validate the harmfulness of the anti-patterns identified.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

19 extracted references · 18 canonical work pages

[7]

Taibi, V

D. Taibi, V. Lenarduzzi. ”On the Definition of Microservice Bad Smells.” IEEE Software 35(3): 56-62 (2018)

work page 2018
[1]

However, many companies migrated without experience on microservices, mainly learning how to migrate from books or from practitioners’ blogs

Chapter 1 Microservices Anti-Patterns: A Taxonomy Davide Taibi, Valentina Lenarduzzi, Claus Pahl Abstract Several companies are re-architecting their monolithic information sys- tems with microservices. However, many companies migrated without experience on microservices, mainly learning how to migrate from books or from practitioners’ blogs. Because of t...

work page 2019
[4]

S. Newman. Building Microservices. O’Reilly 2015

work page 2015
[5]

Richardson

C. Richardson. ”Microservice Patterns”. Manning Publications 2017

work page 2017
[6]

Taibi, V

D. Taibi, V. Lenarduzzi, C. Pahl. ”Processes, Motivations and Issues for Mi- grating to Microservices Architectures: An Empirical Investigation” IEEE Cloud Computing, 4(5), 22-32. 10.1109/MCC.2017.4250931

arXiv 2017
[10]

T. Saleh. ”Microservices Antipatterns”. QCon London 2016

work page 2016
[12]

V. Alagarasan

"V. Alagarasan" (Asurion) ”Microservices Antipatterns” Microservices-Summit. June 2016 New York

work page 2016
[13]

Bryant (SpectoLabs)

D. Bryant (SpectoLabs). ”The seven (more) deadly sins of microservices”. O’Reilly OSCON 2016 London

work page 2016

Show all 19 references

[14]

Taibi, V

D. Taibi, V. Lenarduzzi, C. Pahl, A. Janes. ”Microservices in Agile Software Development: a Workshop-Based Study into Issues, Advantages, and Disadvan- tages” XP ’17 Workshops, 2017, Cologne, Germany

2017
[17]

DECOR: A Method for the Specification and Detection of Code and Design Smells,

N. Moha, Y. G. Gueheneuc, L. Duchien and A. F. Le Meur, "DECOR: A Method for the Specification and Detection of Code and Design Smells," in IEEE Trans- actions on Software Engineering, vol. 36, no. 1, pp. 20-36, Jan.-Feb. 2010

2010
[18]

Identifying Architectural Bad Smells,

J. Garcia, D. Popescu, G. Edwards and N. Medvidovic, "Identifying Architectural Bad Smells," 2009 13th European Conference on Software Maintenance and Reengineering, Kaiserslautern, 2009, pp. 255-258

2009
[19]

Microservice API Patterns. (2018). https://microservice-api-patterns.org Last ac- cessed: 2019-06-05

2018
[20]

Soldani, D

J. Soldani, D. A.Tamburri, W. van den Heuvel. ”The pains and gains of microser- vices: A Systematic grey literature review.” Journal of Systems and Software 146: 215-232 (2018)

2018
[21]

Balalaie, A

A. Balalaie, A. Heydarnoori, P. Jamshidi, D. A. Tamburri, Theo Lynn ”Microser- vices migration patterns.” Software, Practices and Experience 48(11): 2019-2042 (2018)

2018
[26]

Azadi, F

U. Azadi, F. Arcelli Fontana, D. Taibi ”Architectural Smells Detected by Tools: a Catalogue Proposal.” International Conference on Technical Debt (TechDebt 2019), May

2019
[30]

V Lenarduzzi, A Sillitti, D Taibi. ”A survey on code analysis tools for software maintenance prediction.” International Conference in Software Engineering for Defence Applications (SEDA) 2018 1 Microservices Anti-Patterns: A Taxonomy 19

2018
[2017]

Vol. 92, pp. 223-235, DOI: 10.1016/j.infsof.2017.08.008

2017 doi
[2018]

and 13 participants of the international DevOps conference in Helsinki (December 2018). During the interviews, we first introduced our goals to the participants and then asked them if they had at least two years of experience in developing microservices-based systems, so as to...

2018
[2019]

Available: http://arxiv.org/abs/1902.06282

[Online]. Available: http://arxiv.org/abs/1902.06282

1902 arXiv

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [7]

Taibi, V

D. Taibi, V. Lenarduzzi. ”On the Definition of Microservice Bad Smells.” IEEE Software 35(3): 56-62 (2018)

work page 2018

[2] [1]

However, many companies migrated without experience on microservices, mainly learning how to migrate from books or from practitioners’ blogs

Chapter 1 Microservices Anti-Patterns: A Taxonomy Davide Taibi, Valentina Lenarduzzi, Claus Pahl Abstract Several companies are re-architecting their monolithic information sys- tems with microservices. However, many companies migrated without experience on microservices, mainly learning how to migrate from books or from practitioners’ blogs. Because of t...

work page 2019

[3] [4]

S. Newman. Building Microservices. O’Reilly 2015

work page 2015

[4] [5]

Richardson

C. Richardson. ”Microservice Patterns”. Manning Publications 2017

work page 2017

[5] [6]

Taibi, V

D. Taibi, V. Lenarduzzi, C. Pahl. ”Processes, Motivations and Issues for Mi- grating to Microservices Architectures: An Empirical Investigation” IEEE Cloud Computing, 4(5), 22-32. 10.1109/MCC.2017.4250931

arXiv 2017

[6] [10]

T. Saleh. ”Microservices Antipatterns”. QCon London 2016

work page 2016

[7] [12]

V. Alagarasan

"V. Alagarasan" (Asurion) ”Microservices Antipatterns” Microservices-Summit. June 2016 New York

work page 2016

[8] [13]

Bryant (SpectoLabs)

D. Bryant (SpectoLabs). ”The seven (more) deadly sins of microservices”. O’Reilly OSCON 2016 London

work page 2016