logoalt Hacker News

tatrionstoday at 8:16 AM3 repliesview on HN

The bounded surface area insight is right, but the actual forcing function is context window size. Small codebase fits in context, LLM can reason end-to-end. You get the same containment with well-defined modules in a monolith if your tooling picks the right files to feed into the prompt.

Interesting corollary: as context windows keep growing (8k to 1M+ in two years), this architectural pressure should actually reverse. When a model can hold your whole monolith in working memory, you get all the blast radius containment without the operational overhead of separate services, billing accounts, and deployment pipelines.


Replies

stingraycharlestoday at 9:02 AM

This makes no sense as you’re able to have similar interfaces and contracts using regular code.

Microservices solve an organizational problem mostly — teams being able to work completely independently, do releases independently, etc — but as soon you’re going to actually do that, you’re introducing a lot of complexity (but gain organizational scalability).

This has nothing to do with context sizes.

lyricalstringtoday at 10:01 AM

Agree on the context window framing. If an LLM needs well-defined boundaries to work well, just write clean module interfaces. You don't need a network boundary for that.

The part about "less scrutiny on PR review" and committing straight to main is telling too. That's not really about microservices, that's just wanting to ship faster with less oversight. Works until it doesn't.

show 1 reply
dist-epochtoday at 9:57 AM

Large context windows cost more money. So the pressure is still there to keep it tight.