In the world of microcontrollers, you're used to building monolithic systems. Your entire application, from reading a sensor to blinking an LED, often lives in a single C/C++ program flashed onto one device. This is simple and efficient for a dedicated task. But what happens when you need to display that sensor data on a website, store it for a year, and let thousands of users see it? A monolithic approach doesn't scale.

Modern web systems use a distributed architecture. Instead of one giant program doing everything, the work is split among specialized services. A web server might handle user requests, an application server runs the business logic, and a database server stores the data. For an IoT application, we add another piece: a gateway that communicates with your hardware. Each part is independent and can be scaled or updated without affecting the others. Think of it less like a single, all-knowing brain and more like a team of specialists who communicate to get a job done.

Just as people communicate in different ways, so do software components. In web architecture, two dominant patterns are Request-Response and Publish-Subscribe.

You're likely familiar with the Publish-Subscribe model from protocols like MQTT. A device (a publisher) sends a message to a central topic, like 'sensor/temperature'. Other devices or services (subscribers) that are interested in that topic receive the message. It's like a radio broadcast; the sender doesn't know or care who is listening. This is great for low-power devices sending frequent updates.

The web, on the other hand, is primarily built on the Request-Response model, using the HTTP protocol. A client (like your browser) sends a specific request to a server, such as 'GET /latest-reading'. The server processes that request and sends a direct response back to that specific client. It’s a direct, one-to-one conversation. The server doesn’t do anything until it receives a request.

To connect your hardware to the web, we use a three-tier architecture. It provides a clear separation of concerns, which is essential for building maintainable and scalable applications.

1. Frontend (Presentation Tier): This is what the user sees and interacts with. It’s the dashboard in a web browser or a mobile app that displays sensor readings, charts, and buttons. It’s built with technologies like HTML, CSS, and JavaScript.

2. Backend (Logic Tier): This is the brain of the operation. It receives data from the IoT gateway, processes it, stores it in a database, and handles requests from the frontend. For example, when you ask for the average temperature over the last 24 hours, the backend queries the database, calculates the average, and sends the result to the frontend. A key concept here is statelessness—each request from the frontend should be self-contained, allowing the backend to handle requests from thousands of users without getting confused.

3. IoT Gateway / Data Tier: For IoT, this tier is twofold. It includes the database where data is stored, but also the crucial gateway. The gateway is a piece of hardware or software that acts as a bridge. It translates low-level protocols from your sensors (like MQTT or a custom serial protocol) into a web-friendly format (like HTTP/JSON) that the backend can understand. It's the translator between the messy physical world and the orderly digital one.

This structure maps the journey of a single data point: a sensor reading is published to a topic, the IoT gateway subscribes to that topic and forwards the reading to a backend endpoint via an HTTP POST request. The backend validates and stores it in the database. Later, a user opens a web page, and the frontend makes an HTTP GET request to the backend, which retrieves the data and displays it.