Module 92: Architecture Patterns

Why each option is right or wrong

• “A single powerful server that runs the whole website” (Incorrect): A monolith is about how the code is deployed, not the hardware.
• “An old project that has been abandoned by its team” (Incorrect): "Monolith" isn't an insult; many active products are monoliths.
• “A database that stores data for every service” (Incorrect): A monolith is an application; it usually has a database, but isn't one.
• “One application deployed as a single unit” is correct.

  A monolith keeps all the features, such as bookings, payments and accounts, in one codebase that's built and deployed together. It can still be well organised inside. Many successful products run as monoliths.

  • Strength: simple to deploy, test and debug.
  • Watch for: tangled code if there are no clear internal boundaries.

📖 Revise: Lesson 1: Monoliths

Why each option is right or wrong

• “Monoliths can scale without any limit at all” (Incorrect): Monoliths can scale far, but not without limit; simplicity is the reason.
• “They don't need automated tests like microservices do” (Incorrect): Monoliths need tests too.
• “Microservices are only allowed for large companies” (Incorrect): Anyone can use them; they're just costly for small teams.
• “Simpler to build, test, deploy and debug” is correct.

  With one codebase, a small team can run everything locally, follow a request in one place, and deploy with one command. Microservices add networks, many deployments and monitoring, which a small team pays for without much benefit.

  • Keep structure: clear modules, so splitting later is possible.
  • Split when: real needs appear.

📖 Revise: Lesson 1: Monoliths

Why each option is right or wrong

• “Each service must be rewritten whenever any other service changes its code” (Incorrect): Well-designed services change independently; that's their main benefit.
• “They can't use databases, only files” (Incorrect): Each service usually has its own database.
• “Every service has to be written in the same programming language and framework” (Incorrect): Services can use different languages; the cost is in running many of them.
• “Network calls can fail, and you must deploy, monitor and version many services” is correct.

  Calls between services travel over a network, so they can be slow or fail, and you need timeouts and retries. Each service needs its own deployment, monitoring, logs and version management. That's a lot of extra work.

  • Debugging: a request may cross several services.
  • Needs: tracing, good automation, experienced teams.

📖 Revise: Lesson 2: Microservices

Why each option is right or wrong

• “When a single developer wants each feature kept in its own tidy, separate folder” (Incorrect): Tidy folders fit inside a modular monolith, without network costs.
• “From day one, for every new product” (Incorrect): Starting with microservices adds costs before you know the boundaries.
• “When the codebase passes a set size, such as 50,000 lines of code in total” (Incorrect): Size alone isn't the signal; team independence and uneven scaling are.
• “Many teams need to deploy parts independently and those parts scale differently” is correct.

  Microservices help when several teams keep blocking each other in one codebase, or when one part, like search, needs far more capacity than the rest. Splitting lets each team deploy on its own schedule and scale its part separately.

  • Signs: slow coordinated releases, very uneven load.
  • Not a reason: because big companies use them.

📖 Revise: Lesson 2: Microservices

Why each option is right or wrong

• “Only the UI talks to the database, skipping logic” (Incorrect): That scatters business rules into the UI, where they're hard to reuse and test.
• “Any layer can call any other layer freely” (Incorrect): Free calls create tangled dependencies, losing the benefit of layers.
• “The data layer calls the presentation layer to update it” (Incorrect): Lower layers shouldn't depend on the UI; calls go downwards.
• “Presentation calls business logic, which calls data access” is correct.

  Each layer talks to the one below it: the UI or API layer calls business logic, and business logic calls the data layer. This keeps rules in one place and lets you change the UI or database with less impact.

  • Avoid: the UI querying the database directly.
  • Benefit: each layer can be tested on its own.

📖 Revise: Lesson 3: Layered architecture

Why each option is right or wrong

• “Use only one framework across the whole project” (Incorrect): It's about direction of dependencies, not the number of frameworks.
• “Keep every file short, with each class doing one job and under 50 lines of code” (Incorrect): Small, focused files are good habits, but the core rule is about the direction of dependencies.
• “The database sits at the centre and everything depends on it” (Incorrect): That's the opposite: business rules are at the centre.
• “Business rules don't depend on frameworks, databases or the UI; dependencies point inward” is correct.

  At the centre is your domain: the rules of the business. Frameworks, databases and the web are outer details that depend on the centre, not the other way round. You can then test rules without a database and swap tools with less pain.

  • How: the core defines interfaces; outer layers implement them.
  • Cost: more structure, worth it for complex rules.

📖 Revise: Lesson 4: Clean architecture

Why each option is right or wrong

• “A monolith that runs on two servers behind a load balancer” (Incorrect): That's a normal scaled monolith, not a distributed monolith.
• “A database cluster spread across several regions” (Incorrect): That's a distributed database.
• “A CDN that serves the monolith's static files” (Incorrect): A CDN serves files; it doesn't make a distributed monolith.
• “Microservices so tightly coupled they must be deployed together” is correct.

  If services share a database, call each other for everything, or must change together, you get the costs of microservices, such as networks and many deployments, with none of the independence. It's often worse than a plain monolith.

  • Warning sign: one change needs releases of several services.
  • Fix: clearer boundaries, or merge them back.

📖 Revise: Lesson 2: Microservices

Why each option is right or wrong

• “Because databases are cheap, so one each costs little” (Incorrect): Cost isn't the reason; independence is.
• “Because sharing a database between services isn't possible” (Incorrect): It's possible, which is why it's a common mistake.
• “So each service can be backed up on its own schedule” (Incorrect): Separate backups are a side effect; the main reason is that services can change without breaking each other.
• “So services don't break each other through a shared database” is correct.

  If several services read and write the same tables, one team changing a column can break others, and they can't deploy independently. When each service owns its data and others ask through its API, changes stay contained.

  • Sharing data: through APIs or events.
  • Trade-off: reporting across services needs more work.

📖 Revise: Lesson 2: Microservices

Why each option is right or wrong

• “Several separate apps sharing one server” (Incorrect): That's several apps; a modular monolith is one app.
• “A frontend framework that splits each web page into small reusable components” (Incorrect): It's an architecture style for the whole app, not a frontend framework.
• “A monolith with no internal structure at all” (Incorrect): The point is clear internal structure.
• “One deployable app split into clear internal modules with boundaries” is correct.

  A modular monolith is deployed as one unit, but inside it's divided into modules, like bookings, payments and accounts, that talk through defined interfaces. It keeps the simplicity of one app with much of the clarity of separate services.

  • Enforce boundaries: with folders, rules and code review.
  • Later: a module can become a service if needed.

📖 Revise: Lesson 5: Choosing a pattern

Why each option is right or wrong

• “By copying whatever the biggest tech companies use” (Incorrect): Their scale and teams differ from yours.
• “By picking whatever is most popular this year” (Incorrect): Trends don't match your needs automatically.
• “By choosing the most advanced option, to be ready for growth” (Incorrect): Over-building early adds cost; choose for current needs with room to change.
• “By team size, requirements, scale and skills, and write down why” is correct.

  The right pattern depends on your situation: how many developers, what the system must do, how much load, and what the team knows well. Recording the reasons in a decision record helps future you understand and revisit the choice.

  • ADR: architecture decision record.
  • Revisit: when the situation changes.

📖 Revise: Lesson 5: Choosing a pattern