The weekly letter from Systems Thinking Lab: systems thinking insights for junior engineers, framed through the seven building blocks.
You asked an AI to help you build something, and it put the whole thing inside one service. I have written about this before: a Service is a waiter, it takes the order and comes back with an answer. Ask AI to write the code for your app and it puts everything behind that one order: validate the input, hit the database, send the email, all before the response goes back. It works in the demo. In production the email step is slow, so every user stares at a spinner while your server waits on someone else's mail service.
Ask the same AI to design that system before you write a line of code, and you get the opposite mistake. Same AI. Same app. Opposite failure. You and one other engineer are building an app that lets roommates split rent and bills. Ask AI to design it, and it hands you five services: auth, billing, notifications, an API gateway in front of all of them, and a message broker connecting them.
Five services sounds manageable until you count what is actually inside each one. Auth is not one thing. It is a Service, a Relational Database of user accounts, and a Key-Value Store holding sessions: three building blocks. Billing is a Service plus its own Relational Database of charges: two more. Notifications is a Service, a Queue, and a Worker to send the email: three more. The API gateway is a fourth Service sitting in front of the rest, and the message broker is its own Queue. Ten building blocks, minimum, spread across five separate deployments, for a team of two.
What the app actually needs looks nothing like that. Someone logs in and adds a bill: one Service. The bill has to know which users it belongs to and how it is split: one Relational Database. When someone marks a bill paid, you want to email the other roommates, and that does not need to happen while anyone is watching a spinner, so it goes on a Queue, and a Worker picks it up a few seconds later. One Service, one Relational Database, one Queue and Worker: the whole system. Four blocks, one deployment, against ten blocks spread across five.
Ask AI to write code and it defaults to the plainest possible shape: one function, one service, request in, response out. It never reaches for a queue, because a queue is a decision about what can wait, not the plain shape of code. Ask AI to design a system on its own and it defaults to the most-discussed shape it has read about, which is how large companies solve problems you do not have. Same root cause both times: it is matching the genre of your prompt, not your actual constraints.
This is why the blocks matter more than the word "service." A microservice is not a building block. It is a whole deployment that can contain two or three of them. Count in services and "five" sounds like five things to build. Count in blocks and it is ten pieces you have to build, wire together, and keep alive, spread across five deployments you run separately. Against four pieces in one.
Microservices earn their cost when separate teams need to ship without waiting on each other, when one part needs different hardware, or when one failure cannot be allowed to take down everything else. Two people building one app have none of that pressure. What you need is one place to change things, one deploy, one thing to reason about at 11pm: a monolith. Not the beginner version of something you graduate out of. At your stage, it is the correct design.
Run every piece of the AI's answer, whether it built too little or too much, through one question: does the pressure that justifies this exist on my team, right now? Multiple teams stepping on each other's deploys. A component that needs different hardware. Traffic you can already measure, not traffic you are imagining for next year. If that pressure is not real, the piece comes out, whether it is a missing queue or an extra service.
That is why I teach the seven building blocks in Course 1 before anyone draws a single box. Know what each one is for, and you can look at any answer, AI's or your own, and ask what it is actually built to survive.
You do not fix the answer the AI gave you. You check the pressure behind every piece of it.
P.S. If you want the repeatable version of that question, I wrote up the full decision framework: one question per building block, so you can point at any requirement and know exactly what it needs. https://systemthinkinglab.ai/learn/building-blocks/decision-framework/