Session 04: System Architecture — Monolith, Microservices, and Queues

---

Part 1: Monolith and Microservices — A Choice Shaped by History

You already understand frontend, backend, database, and API — the basic building blocks. The next question: how are those pieces organized and connected as the system grows?

Why you shouldn't start with microservices

Picture opening a small restaurant. At first, one cook handles everything — picking ingredients, cooking, washing dishes, and taking payment. That's a monolith: one person doing it all, simple and efficient at small scale. Only when the place grows into a restaurant chain do you need specialized roles: head chef, cashier, warehouse manager. That's microservices.

Amazon, Netflix, Uber — the most famous microservices systems in the world — all started as monoliths. They moved to microservices when the monolith actually started causing problems: teams too large to coordinate, deploys too slow, scaling costs too high.

Starting with microservices before you need them is one of the most common architecture mistakes. You pay the full cost of a distributed system (network failures, guaranteeing data consistency, complex operations) without being at the scale to reap the benefits.

Signs the monolith is becoming a real problem:

• Every deploy requires coordinating with five or more teams
• The automated test suite runs for two hours and can't run in parallel
• A bug in the payment module takes down the whole app, including unrelated parts
• Team A has to wait for Team B to merge before it can release

If you don't see these signs, proposing microservices is just "architecture tourism" — it sounds modern but doesn't solve a real problem.

The real cost of microservices

When you move to microservices, some problems disappear and new ones appear. These are the ones a PM will feel directly.

Distributed tracing — debugging gets much harder: Picture a user request passing through five services like a parcel moving through five post offices. When the parcel goes missing, you have to trace it office by office. In microservices, when there's a bug, the fault could sit in any service along the chain. Debugging takes longer and needs specialized tools like Jaeger or Zipkin to follow the trail.

Data consistency — data can get out of sync: The Order Service's database and the Inventory Service's database are two completely separate databases. When a user places an order, how do you make sure stock gets decremented at the right moment? If the Order Service saves successfully but the Inventory Service fails, the system lands in an inconsistent state — the order is created but stock wasn't reduced. Solving this is far more complex than in a monolith.

Operational overhead — operations multiply: Instead of monitoring one service, you're monitoring twenty. Instead of one deploy pipeline, you have twenty. Infrastructure costs rise noticeably before the benefits show up to offset them.

---

Part 2: Async Processing and Message Queues

Why not everything needs to be real-time

When a user places an order, they need to know the order is confirmed right away. But that doesn't mean everything tied to the order has to happen in that same instant.

Picture dropping off a package at the post office. The clerk takes it, stamps it "Received," and hands you the receipt immediately. Sorting the package, moving it to the transit hub, notifying the recipient — all of that happens afterward, without you standing there waiting.

Things that can safely happen later (async processing):

• Sending confirmation email/SMS
• Updating analytics figures
• Calculating and updating loyalty points
• Syncing to the ERP/accounting system
• Generating a PDF invoice
• Notifying the seller

If all of this had to happen at once within a single request, the user would wait for everything to finish before seeing the success screen. Worse, if the email step times out, a perfectly valid order might get canceled along with it — even though nothing was wrong with the order itself.

Message Queue — The Post Office of the System

A message queue works like a post office: the sender (producer) drops a letter into the mailbox (queue), and the receiver (consumer) picks it up and processes it at its own pace. Neither side needs to know the other exists, and they don't need to be running at the same time.

The common queue systems you'll hear about: RabbitMQ, Apache Kafka, AWS SQS.

Kafka is used for event streaming at large scale — Shopee, Grab, or any platform that needs to handle millions of events per second. SQS is the simpler choice for teams that don't want to run their own infrastructure.

What a PM needs to know when designing a feature:

When designing a notification feature or a complex workflow, ask the devs: "Which parts of this flow are processed asynchronously?" If the answer is "everything is synchronous," that can be a sign of a rushed design — and the source of production timeout errors down the line.

---

Part 3: Caching — Speed Comes from Controlled Duplication

The cache layers

Caches exist at multiple layers, each solving a different problem. Think of working in an office: the documents you use most sit right on your desk (fastest), the ones you use less go in the office cabinet (a bit slower), and archived documents live in the basement storeroom (slowest). Software caching works the same way.

Browser cache: CSS, JS, and image files are stored on the user's device. Next time they visit, the browser doesn't need to re-download them. A PM needs to know this when shipping a new feature: some users still see the old UI because their browser is using the old version from cache. The fix is a technique called "cache-busting" — renaming files to force the browser to reload.

CDN cache: Images and static content are stored on edge servers geographically closest to the user. When you swap out a promo banner, if you don't purge the CDN cache, users keep seeing the old image for 24 hours. A PM should ask: "After we push live, does the change show up immediately? How long until the CDN updates?"

Application cache (Redis): The results of complex queries or frequently-read data are stored in Redis — a high-speed database. For example: the list of top-selling products is cached for 5 minutes instead of querying the database every time someone views the page.

The cache invalidation problem: This is one of the hardest problems in computer science — and that's not an exaggeration. When do you clear the cache? Too early: the database takes too many queries. Too late: users see stale data. When a PM asks to "update the price instantly when an admin changes it," that's really a cache invalidation request — the estimate is usually higher than you'd expect, and there's a good reason for it.

---

Part 4: Reading an Architecture Diagram Like a PM

What to look for in an architecture diagram

When a dev or architect walks through an architecture diagram, you don't need to understand every technical detail. But there are four things you should actively look for.

Single points of failure: Look for any service that, if it fails, takes down the entire system. If one exists, that's a risk that needs an answer.

External dependencies: How many third-party services does the system rely on? Each dependency is a potential source of downtime. When Stripe has an outage, do your payments go down with it?

Data flow: Which services does data pass through before it's stored? Each step adds latency and one more point that can fail.

Synchronous vs asynchronous: Which parts of the flow are blocking (the user has to wait), and which are non-blocking (the user gets a result immediately while the rest runs in the background)?

Questions a PM should ask when reviewing architecture

• "If service X fails, are users affected? How badly?"
• "Which parts are processed asynchronously? If the queue backs up, will users know?"
• "Which external dependencies are essential? Do we have a fallback plan?"
• "How does this architecture decision affect our ability to deliver features on the six-month roadmap?"

You don't need to validate whether it's technically right or wrong — that's engineering's job. But you do need to understand enough to make product decisions that fit the real risks and tradeoffs.

---

Further Reading

• Microservices — Martin Fowler — The original article defining microservices, explaining when to use them and when not to.
• MonolithFirst — Martin Fowler — The practical reasons a monolith is usually the right starting point, and when you should finally move to microservices.
• AWS: What is a Message Queue? — An introduction to message queues from a practical angle, with common use cases.
• Caching Best Practices — AWS — A guide to the cache layers and when to use each one.
• The System Design Primer — GitHub — The most widely referenced system design compendium, with visual diagrams for every concept.

---