Serverless and Application service
Monolithic
Everything is in one big program. Hard to change one part without affecting the whole thing.
Example: A big store website where login, product catalog, checkout, and payment all exist in one app.
Monolithic = a single chocolate cake: if one layer goes wrong, the whole cake is affected.
Tiered architecture
Tiered architecture (or n-tier architecture) is a way of organizing an application into layers (tiers), each with a specific job.
Common example: 3-tier architecture
Presentation Tier (Front-end) – What the user sees and interacts with.
Example: Website pages, mobile app screens.
Logic Tier (Application/Business Layer) – Where the app makes decisions and processes data.
Example: Calculating prices, validating login, processing orders.
Data Tier (Database) – Where all the information is stored and retrieved.
Example: User accounts, product inventory, transaction records.
Think of a restaurant:
Waiter (Presentation) → takes your order.
Chef (Logic) → cooks and prepares the food.
Storage/Pantry (Data) → stores all ingredients.
This separation makes the system easier to maintain, update, and scale, compared to a single monolithic block.
Synchronous (Sync)
Things happen one after another.
Each task waits for the previous one to finish before starting.
Analogy: Standing in line at a shop — you wait until the cashier finishes with the person ahead before it’s your turn.
Example in tech: A web request that waits until the server finishes and sends back a response.
Asynchronous (Async)
Tasks can happen independently, at the same time.
One task doesn’t have to wait for another.
Analogy: Ordering food online — you place the order and continue doing other things while the restaurant prepares your food.
Example in tech: Sending an email — your app doesn’t wait until the email is delivered, it just queues it and moves on.
👉 In short:
Sync = wait for it to finish
Async = don’t wait, keep going
Microservices
The app is broken into small independent parts (services), each doing one job.
Example: One service handles login, another handles payments, another handles catalog. They can be updated without breaking the others.
Microservices = separate cupcakes: each one can be fixed or replaced without touching the others.
Event-driven architecture (EDA)
Event-driven architecture (EDA) is a way of designing software where things happen in response to events.
An event is any significant action or change, like:
A user clicks a button
A new order is placed
A sensor detects motion
How it works:
Event occurs → something happens in the system.
Event is captured → a component called an event listener notices it.
Event is processed → another component takes action based on the event.
Analogy:
Think of a doorbell system:
Pressing the doorbell = event
Bell rings = listener reacts
You open the door = action triggered
Key points:
Components don’t constantly check for changes—they only act when something happens.
Makes the system fast, flexible, and scalable.
Last updated