[{"data":1,"prerenderedAt":712},["ShallowReactive",2],{"blog-blog_en-page-8":3},{"posts":4,"totalPosts":711,"totalPages":129,"currentPage":129},[5,194,285,556],{"id":6,"title":7,"body":8,"cover":178,"date":179,"description":180,"draft":181,"extension":182,"meta":183,"navigation":184,"path":185,"seo":186,"stem":187,"tags":188,"__hash__":193},"blog_en\u002Fen\u002Fblog\u002Fmonolith-vs-microservices-die-richtige-wahl-fuer-ihre-teamgroesse.md","Monolith vs. Microservices: Choosing the Right Architecture for Your Team Size",{"type":9,"value":10,"toc":173},"minimark",[11,15,20,36,133,137,156,160,169],[12,13,14],"p",{},"The monolith versus microservices debate is one of the most consequential architecture decisions a team makes, yet it is often driven by trends rather than context. Microservices are not progress in themselves; they are an answer to specific problems that many teams do not yet have.",[16,17,19],"h2",{"id":18},"when-a-monolith-is-the-better-choice","When a Monolith Is the Better Choice",[12,21,22,23,27,28,31,32,35],{},"For most teams in early stages, a well-structured monolith is the superior option. ",[24,25,26],"strong",{},"Teams of fewer than ten engineers"," do not benefit from the distributed complexity that microservices introduce. Network latency, distributed transactions, and service discovery are problems that overwhelm a small team. ",[24,29,30],{},"Products still searching for product-market fit"," need maximum iteration speed. A monolith allows domain boundaries to be shifted without coordinating deployments across multiple services. ",[24,33,34],{},"Domains that are not yet fully understood"," should not be carved into services. An early wrong cut creates more coupling than a thoughtful monolith.",[37,38,43],"pre",{"className":39,"code":40,"language":41,"meta":42,"style":42},"language-bash shiki shiki-themes github-light github-dark","# Warning sign: microservice overhead for a small team\n# Starting a local development environment with 12 services\ndocker-compose up --scale user-service=1 \\\n                  --scale order-service=1 \\\n                  --scale payment-service=1 \\\n                  --scale notification-service=1\n# Onboarding time: 2-3 days for the local environment alone.\n# For a team of 4 developers, this is not progress.\n","bash","",[44,45,46,55,61,85,98,110,121,127],"code",{"__ignoreMap":42},[47,48,51],"span",{"class":49,"line":50},"line",1,[47,52,54],{"class":53},"sJ8bj","# Warning sign: microservice overhead for a small team\n",[47,56,58],{"class":49,"line":57},2,[47,59,60],{"class":53},"# Starting a local development environment with 12 services\n",[47,62,64,68,72,76,79,82],{"class":49,"line":63},3,[47,65,67],{"class":66},"sScJk","docker-compose",[47,69,71],{"class":70},"sZZnC"," up",[47,73,75],{"class":74},"sj4cs"," --scale",[47,77,78],{"class":70}," user-service=",[47,80,81],{"class":74},"1",[47,83,84],{"class":74}," \\\n",[47,86,88,91,94,96],{"class":49,"line":87},4,[47,89,90],{"class":74},"                  --scale",[47,92,93],{"class":70}," order-service=",[47,95,81],{"class":74},[47,97,84],{"class":74},[47,99,101,103,106,108],{"class":49,"line":100},5,[47,102,90],{"class":74},[47,104,105],{"class":70}," payment-service=",[47,107,81],{"class":74},[47,109,84],{"class":74},[47,111,113,115,118],{"class":49,"line":112},6,[47,114,90],{"class":74},[47,116,117],{"class":70}," notification-service=",[47,119,120],{"class":74},"1\n",[47,122,124],{"class":49,"line":123},7,[47,125,126],{"class":53},"# Onboarding time: 2-3 days for the local environment alone.\n",[47,128,130],{"class":49,"line":129},8,[47,131,132],{"class":53},"# For a team of 4 developers, this is not progress.\n",[16,134,136],{"id":135},"when-microservices-pay-off","When Microservices Pay Off",[12,138,139,140,143,144,147,148,151,152,155],{},"Microservices have genuine value, but only under specific conditions. ",[24,141,142],{},"Teams large enough to own individual services"," need clear ownership boundaries. The rule of thumb: one service per team, not multiple teams per service. ",[24,145,146],{},"Established domain boundaries"," are a prerequisite. Microservices should reflect boundaries that already exist in the business, not those that are hoped for. ",[24,149,150],{},"Different scaling requirements per service"," can justify microservices: a compute-intensive service needs different resources than a lightweight API gateway. ",[24,153,154],{},"Organisational structures that enable independent deployments"," are essential. Conway's Law applies in both directions.",[16,157,159],{"id":158},"why-this-matters","Why This Matters",[12,161,162,163,168],{},"The wrong architecture for a team's size creates overhead that never pays off. Conway's Law describes precisely what happens in practice: the architecture of a system mirrors the communication structure of the organisation. Cutting services according to wishful thinking rather than actual team boundaries creates coordination costs with no return. An ",[164,165,167],"a",{"href":166},"\u002Fen\u002F#packages","Architecture & AI Review"," evaluates the current stack in the context of team size and delivers a clear recommendation for which architectural direction will hold over the next 18 months.",[170,171,172],"style",{},"html pre.shiki code .sJ8bj, html code.shiki .sJ8bj{--shiki-default:#6A737D;--shiki-dark:#6A737D}html pre.shiki code .sScJk, html code.shiki .sScJk{--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .sZZnC, html code.shiki .sZZnC{--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .sj4cs, html code.shiki .sj4cs{--shiki-default:#005CC5;--shiki-dark:#79B8FF}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":42,"searchDepth":57,"depth":57,"links":174},[175,176,177],{"id":18,"depth":57,"text":19},{"id":135,"depth":57,"text":136},{"id":158,"depth":57,"text":159},null,"2026-02-03","Microservices are seen as modern, but for many teams they are an expensive misunderstanding. When each architecture actually makes sense.",false,"md",{},true,"\u002Fen\u002Fblog\u002Fmonolith-vs-microservices-die-richtige-wahl-fuer-ihre-teamgroesse",{"title":7,"description":180},"en\u002Fblog\u002Fmonolith-vs-microservices-die-richtige-wahl-fuer-ihre-teamgroesse",[189,190,191,192],"Software Architecture","Microservices","Backend Development","Engineering Leadership","zH3hAzlqozAyHgYzRgmCa4-6vFOY4nfoNZ0t0NvI_h4",{"id":195,"title":196,"body":197,"cover":178,"date":275,"description":276,"draft":181,"extension":182,"meta":277,"navigation":184,"path":278,"seo":279,"stem":280,"tags":281,"__hash__":284},"blog_en\u002Fen\u002Fblog\u002Ftechnische-schulden-was-sie-ein-unternehmen-wirklich-kosten.md","Technical Debt: What It Really Costs a Company",{"type":9,"value":198,"toc":270},[199,202,206,221,225,228,262,264],[12,200,201],{},"Technical debt is often treated as a developer problem, one that will sort itself out eventually or can be addressed in a quieter quarter. Reality looks different: the costs appear in product timelines, in the difficulty of retaining experienced engineers, and in investor questions during due diligence. Technical debt is a business risk.",[16,203,205],{"id":204},"the-three-forms-of-technical-debt","The Three Forms of Technical Debt",[12,207,208,209,212,213,216,217,220],{},"Not all technical debt is created equal. ",[24,210,211],{},"Deliberate debt"," consists of trade-offs a team makes with open eyes: a shortcut taken to hit a launch date, with an explicit plan to address it later. This kind of debt is legitimate when it is documented and actually paid back. ",[24,214,215],{},"Accidental debt"," arises through neglect: outdated dependencies without security patches, missing tests that nobody added, configurations that nobody understands any more. ",[24,218,219],{},"Architectural debt"," is the most expensive form: initial design decisions that were wrong or have become outdated and run through the entire system. These often arise not from bad decisions but from decisions that were correct for an earlier stage of the company.",[16,222,224],{"id":223},"where-the-costs-become-visible","Where the Costs Become Visible",[12,226,227],{},"Technical debt manifests in concrete, measurable costs:",[229,230,231,238,244,250,256],"ul",{},[232,233,234,237],"li",{},[24,235,236],{},"Extended feature development:"," Every new function touches five files instead of one because the boundaries between modules were never cleanly drawn.",[232,239,240,243],{},[24,241,242],{},"Knowledge concentration:"," Only one or two developers fully understand critical system areas. Holidays or resignations become organisational risks.",[232,245,246,249],{},[24,247,248],{},"Talent turnover:"," Experienced developers leave companies because working in a chaotic codebase is frustrating and professionally demoralising.",[232,251,252,255],{},[24,253,254],{},"Difficult onboarding:"," New developers need months to become productive because the codebase has no discernible structure.",[232,257,258,261],{},[24,259,260],{},"Due diligence risks:"," Investors and acquirers conducting technical audits find problems that reduce valuations or block deals.",[16,263,159],{"id":158},[12,265,266,267,269],{},"The right time to address technical debt is before the next growth phase, not after. Growth on an unstable foundation means every new feature is more expensive than the last. An ",[164,268,167],{"href":166}," creates clarity about which debts are critical, which remain tolerable, and in what order remediation makes economic sense.",{"title":42,"searchDepth":57,"depth":57,"links":271},[272,273,274],{"id":204,"depth":57,"text":205},{"id":223,"depth":57,"text":224},{"id":158,"depth":57,"text":159},"2026-01-27","Technical debt is not just a developer concern. It translates directly into development time, team morale, and missed market opportunities.",{},"\u002Fen\u002Fblog\u002Ftechnische-schulden-was-sie-ein-unternehmen-wirklich-kosten",{"title":196,"description":276},"en\u002Fblog\u002Ftechnische-schulden-was-sie-ein-unternehmen-wirklich-kosten",[282,189,283,192],"Technical Debt","Startup","ZowUcJWyUmZpSnNNWTEcP1LhosfdFHMDeOBRUT0xwRQ",{"id":286,"title":287,"body":288,"cover":178,"date":546,"description":547,"draft":181,"extension":182,"meta":548,"navigation":184,"path":549,"seo":550,"stem":551,"tags":552,"__hash__":555},"blog_en\u002Fen\u002Fblog\u002Fapi-first-entwicklung-strategischer-vorteil-fuer-wachsende-teams.md","API-First Development: How a Clean API Strategy Saves Months",{"type":9,"value":289,"toc":541},[290,293,297,311,495,499,530,532,538],[12,291,292],{},"APIs are the connective tissue of modern software, yet most teams treat their design as an afterthought. Implementation comes first, documentation follows, then corrections. This costs months that no project has and creates dependencies that no team wanted. The API-first approach reverses that order.",[16,294,296],{"id":295},"what-api-first-means","What API-First Means",[12,298,299,302,303,306,307,310],{},[24,300,301],{},"Contract-first"," is the core of the approach: the OpenAPI specification is written before a single line of implementation code exists. This enforces clarity around resources, data models, and error codes before technical decisions become hard to reverse. ",[24,304,305],{},"Parallel development"," becomes structurally possible as a result. Frontend and backend teams can work simultaneously because the contract serves as shared ground truth. ",[24,308,309],{},"Mock servers from day one"," allow frontend teams to develop against a realistic API simulation without waiting for the backend.",[37,312,316],{"className":313,"code":314,"language":315,"meta":42,"style":42},"language-yaml shiki shiki-themes github-light github-dark","# OpenAPI specification as a contract before implementation\nopenapi: \"3.0.3\"\ninfo:\n  title: Order API\n  version: \"1.0.0\"\npaths:\n  \u002Forders:\n    post:\n      summary: Place an order\n      requestBody:\n        required: true\n        content:\n          application\u002Fjson:\n            schema:\n              $ref: \"#\u002Fcomponents\u002Fschemas\u002FOrderRequest\"\n      responses:\n        \"201\":\n          description: Order created\n        \"422\":\n          description: Validation error\n","yaml",[44,317,318,323,336,344,354,364,371,378,385,396,404,415,423,431,439,450,458,466,477,485],{"__ignoreMap":42},[47,319,320],{"class":49,"line":50},[47,321,322],{"class":53},"# OpenAPI specification as a contract before implementation\n",[47,324,325,329,333],{"class":49,"line":57},[47,326,328],{"class":327},"s9eBZ","openapi",[47,330,332],{"class":331},"sVt8B",": ",[47,334,335],{"class":70},"\"3.0.3\"\n",[47,337,338,341],{"class":49,"line":63},[47,339,340],{"class":327},"info",[47,342,343],{"class":331},":\n",[47,345,346,349,351],{"class":49,"line":87},[47,347,348],{"class":327},"  title",[47,350,332],{"class":331},[47,352,353],{"class":70},"Order API\n",[47,355,356,359,361],{"class":49,"line":100},[47,357,358],{"class":327},"  version",[47,360,332],{"class":331},[47,362,363],{"class":70},"\"1.0.0\"\n",[47,365,366,369],{"class":49,"line":112},[47,367,368],{"class":327},"paths",[47,370,343],{"class":331},[47,372,373,376],{"class":49,"line":123},[47,374,375],{"class":327},"  \u002Forders",[47,377,343],{"class":331},[47,379,380,383],{"class":49,"line":129},[47,381,382],{"class":327},"    post",[47,384,343],{"class":331},[47,386,388,391,393],{"class":49,"line":387},9,[47,389,390],{"class":327},"      summary",[47,392,332],{"class":331},[47,394,395],{"class":70},"Place an order\n",[47,397,399,402],{"class":49,"line":398},10,[47,400,401],{"class":327},"      requestBody",[47,403,343],{"class":331},[47,405,407,410,412],{"class":49,"line":406},11,[47,408,409],{"class":327},"        required",[47,411,332],{"class":331},[47,413,414],{"class":74},"true\n",[47,416,418,421],{"class":49,"line":417},12,[47,419,420],{"class":327},"        content",[47,422,343],{"class":331},[47,424,426,429],{"class":49,"line":425},13,[47,427,428],{"class":327},"          application\u002Fjson",[47,430,343],{"class":331},[47,432,434,437],{"class":49,"line":433},14,[47,435,436],{"class":327},"            schema",[47,438,343],{"class":331},[47,440,442,445,447],{"class":49,"line":441},15,[47,443,444],{"class":327},"              $ref",[47,446,332],{"class":331},[47,448,449],{"class":70},"\"#\u002Fcomponents\u002Fschemas\u002FOrderRequest\"\n",[47,451,453,456],{"class":49,"line":452},16,[47,454,455],{"class":327},"      responses",[47,457,343],{"class":331},[47,459,461,464],{"class":49,"line":460},17,[47,462,463],{"class":70},"        \"201\"",[47,465,343],{"class":331},[47,467,469,472,474],{"class":49,"line":468},18,[47,470,471],{"class":327},"          description",[47,473,332],{"class":331},[47,475,476],{"class":70},"Order created\n",[47,478,480,483],{"class":49,"line":479},19,[47,481,482],{"class":70},"        \"422\"",[47,484,343],{"class":331},[47,486,488,490,492],{"class":49,"line":487},20,[47,489,471],{"class":327},[47,491,332],{"class":331},[47,493,494],{"class":70},"Validation error\n",[16,496,498],{"id":497},"common-mistakes-without-an-api-strategy","Common Mistakes Without an API Strategy",[12,500,501,502,505,506,509,510,513,514,517,518,521,522,525,526,529],{},"Without an explicit API strategy, predictable problems emerge. ",[24,503,504],{},"Breaking changes in production"," happen because nobody defined a formal versioning strategy. A renamed field breaks clients that were never informed. ",[24,507,508],{},"Inconsistent naming across endpoints"," develops when different developers assign fields and paths without coordination. ",[44,511,512],{},"user_id",", ",[44,515,516],{},"userId",", and ",[44,519,520],{},"id"," mean the same thing but exist in parallel endpoints. ",[24,523,524],{},"Authentication is bolted on late"," because it was dismissed as an infrastructure concern in the initial design. The result is inconsistent auth patterns and security gaps at transition points. ",[24,527,528],{},"Documentation is permanently outdated"," because it is maintained manually and has no connection to the actual code.",[16,531,159],{"id":158},[12,533,534,535,537],{},"A clear API strategy has direct business value: integrations with third parties are faster because the interface is fully documented and stable. New team members understand system boundaries without weeks of onboarding. Tests can be written against the contract rather than against implementation details. Teams that want to approach this step in a structured way will find a framework in the ",[164,536,167],{"href":166}," that evaluates API design, security considerations, and architecture decisions together.",[170,539,540],{},"html pre.shiki code .sJ8bj, html code.shiki .sJ8bj{--shiki-default:#6A737D;--shiki-dark:#6A737D}html pre.shiki code .s9eBZ, html code.shiki .s9eBZ{--shiki-default:#22863A;--shiki-dark:#85E89D}html pre.shiki code .sVt8B, html code.shiki .sVt8B{--shiki-default:#24292E;--shiki-dark:#E1E4E8}html pre.shiki code .sZZnC, html code.shiki .sZZnC{--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .sj4cs, html code.shiki .sj4cs{--shiki-default:#005CC5;--shiki-dark:#79B8FF}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":42,"searchDepth":57,"depth":57,"links":542},[543,544,545],{"id":295,"depth":57,"text":296},{"id":497,"depth":57,"text":498},{"id":158,"depth":57,"text":159},"2026-01-20","API-first means defining the interface before implementation. Why this makes teams faster and what mistakes happen without this strategy.",{},"\u002Fen\u002Fblog\u002Fapi-first-entwicklung-strategischer-vorteil-fuer-wachsende-teams",{"title":287,"description":547},"en\u002Fblog\u002Fapi-first-entwicklung-strategischer-vorteil-fuer-wachsende-teams",[553,191,189,554],"API Design","API Strategy","Zf4zhleKPTq6VjKdeMybTuAQUD7fK7nlTzgD2QkAJUc",{"id":557,"title":558,"body":559,"cover":178,"date":701,"description":702,"draft":181,"extension":182,"meta":703,"navigation":184,"path":704,"seo":705,"stem":706,"tags":707,"__hash__":710},"blog_en\u002Fen\u002Fblog\u002Fbackend-architektur-5-zeichen-dass-sie-nicht-skaliert.md","5 Signs Your Backend Architecture Won't Scale",{"type":9,"value":560,"toc":696},[561,564,568,583,670,674,685,687,693],[12,562,563],{},"Growth is not an architecture problem, until suddenly it is. Most backend scaling issues do not emerge overnight. They announce themselves through concrete signals that teams under pressure consistently ignore. Recognizing these warning signs early allows targeted intervention before a deployment becomes a risk assessment.",[16,565,567],{"id":566},"technical-warning-signs","Technical Warning Signs",[12,569,570,571,574,575,578,579,582],{},"Three symptoms compound into scaling problems with particular reliability. ",[24,572,573],{},"Deployments take longer than 20 minutes:"," Long build and deployment times are not an infrastructure problem, they are a sign of tight coupling. When a change in one module forces a rebuild and retest of the entire system, clear service boundaries are missing. ",[24,576,577],{},"Bugs appear in unexpected modules:"," An error in the order process that affects the user profile indicates absent domain boundaries. Without clean Bounded Contexts, every change propagates in uncontrolled directions. ",[24,580,581],{},"Database queries dominate performance profiles:"," When nearly every request triggers multiple uncached database queries, a caching layer is missing. This is not a tuning issue; it is a structural architecture deficit.",[37,584,586],{"className":313,"code":585,"language":315,"meta":42,"style":42},"# Warning sign: service with too many direct dependencies\nservice: order-processor\ndependencies:\n  - user-service\n  - inventory-service\n  - payment-service\n  - notification-service\n  - analytics-service\n  - shipping-service\n  - discount-service\n# Any change to one of these services can break order-processor.\n# Seven direct dependencies is not a design, it is a liability.\n",[44,587,588,593,603,610,618,625,632,639,646,653,660,665],{"__ignoreMap":42},[47,589,590],{"class":49,"line":50},[47,591,592],{"class":53},"# Warning sign: service with too many direct dependencies\n",[47,594,595,598,600],{"class":49,"line":57},[47,596,597],{"class":327},"service",[47,599,332],{"class":331},[47,601,602],{"class":70},"order-processor\n",[47,604,605,608],{"class":49,"line":63},[47,606,607],{"class":327},"dependencies",[47,609,343],{"class":331},[47,611,612,615],{"class":49,"line":87},[47,613,614],{"class":331},"  - ",[47,616,617],{"class":70},"user-service\n",[47,619,620,622],{"class":49,"line":100},[47,621,614],{"class":331},[47,623,624],{"class":70},"inventory-service\n",[47,626,627,629],{"class":49,"line":112},[47,628,614],{"class":331},[47,630,631],{"class":70},"payment-service\n",[47,633,634,636],{"class":49,"line":123},[47,635,614],{"class":331},[47,637,638],{"class":70},"notification-service\n",[47,640,641,643],{"class":49,"line":129},[47,642,614],{"class":331},[47,644,645],{"class":70},"analytics-service\n",[47,647,648,650],{"class":49,"line":387},[47,649,614],{"class":331},[47,651,652],{"class":70},"shipping-service\n",[47,654,655,657],{"class":49,"line":398},[47,656,614],{"class":331},[47,658,659],{"class":70},"discount-service\n",[47,661,662],{"class":49,"line":406},[47,663,664],{"class":53},"# Any change to one of these services can break order-processor.\n",[47,666,667],{"class":49,"line":417},[47,668,669],{"class":53},"# Seven direct dependencies is not a design, it is a liability.\n",[16,671,673],{"id":672},"organisational-symptoms","Organisational Symptoms",[12,675,676,677,680,681,684],{},"Architecture problems do not only show up in code, they surface in day-to-day work. ",[24,678,679],{},"Onboarding new developers takes weeks:"," When a new developer needs several weeks to deliver features independently, structural clarity is missing. Good architecture is documentable because it is explainable. Poor architecture lives in the heads of senior engineers. ",[24,682,683],{},"Technical meetings end without decisions:"," When architecture debates are regularly deferred or dissolve into consensus loops, architectural authority is absent. Nobody is empowered or willing to set a binding direction. The result: every team decides locally, and the overall architecture drifts apart.",[16,686,159],{"id":158},[12,688,689,690,692],{},"Architecture problems do not resolve themselves through growth. On the contrary, more developers working on a poorly structured codebase accelerate its decay. The cost of retroactive refactoring grows exponentially with team size. The best time for an architecture review is not after the next funding round, but now. A structured ",[164,691,167],{"href":166}," analyses the current state, identifies concrete risks, and delivers a prioritised action plan that can be reconciled with day-to-day operations.",[170,694,695],{},"html pre.shiki code .sJ8bj, html code.shiki .sJ8bj{--shiki-default:#6A737D;--shiki-dark:#6A737D}html pre.shiki code .s9eBZ, html code.shiki .s9eBZ{--shiki-default:#22863A;--shiki-dark:#85E89D}html pre.shiki code .sVt8B, html code.shiki .sVt8B{--shiki-default:#24292E;--shiki-dark:#E1E4E8}html pre.shiki code .sZZnC, html code.shiki .sZZnC{--shiki-default:#032F62;--shiki-dark:#9ECBFF}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":42,"searchDepth":57,"depth":57,"links":697},[698,699,700],{"id":566,"depth":57,"text":567},{"id":672,"depth":57,"text":673},{"id":158,"depth":57,"text":159},"2026-01-13","Growing teams often fail because of architecture problems that were detectable early. Five warning signs and what they reveal about your stack.",{},"\u002Fen\u002Fblog\u002Fbackend-architektur-5-zeichen-dass-sie-nicht-skaliert",{"title":558,"description":702},"en\u002Fblog\u002Fbackend-architektur-5-zeichen-dass-sie-nicht-skaliert",[708,189,282,709],"Backend Architecture","Scalability","F_7ZFD1JKOrFeawf7Zbq4JSMx5bSfVFSAvJVUnoZzUA",46,1781596426578]