3. Networks and how apps connect

Think of the internet as a giant postal system for data.

When Almaz in Addis Ababa opens the TeleBirr app on her phone, she is essentially sending a letter — except this letter is called a network request, and it travels at nearly the speed of light.

Just like postal letters need an address, every device connected to the internet has a unique address called an IP address (Internet Protocol address). An IP address looks like this: 192.168.1.45 or, in the newer version (IPv6), like 2001:db8::1.

Every server in a data centre has an IP address. Every phone that connects to the internet gets a temporary IP address from the mobile network (Ethio Telecom, for example). When your phone sends a request to a server, the network uses these addresses to route the data through a chain of intermediate routers — the post offices of the internet — until it arrives at the right destination.

IP addresses are perfect for computers but terrible for humans. Nobody wants to memorise 142.250.80.46 every time they want to visit Google.

That is why the internet has a Domain Name System (DNS) — essentially a global phone book that converts human-readable names like google.com or ethiotelecom.et into the numeric IP addresses that routers understand.

Here is what happens step by step when Abebe types ethiotelecom.et into his browser:

1. His browser asks a DNS resolver (usually provided by his ISP or a public service like Google's 8.8.8.8) — "What is the IP address for ethiotelecom.et?"

2. The DNS resolver looks up the answer and responds with the IP address, e.g. 197.156.65.10.

3. Abebe's browser now sends the actual request to that IP address.

4. The server at that IP address responds with the website content.

All of this happens in milliseconds — usually faster than Abebe can blink.

This is why setting up a domain name for your app is one of the first networking tasks every developer learns. You register a name (like myapp.et) with a domain registrar, then create a DNS record pointing that name to your server's IP address.

Once your browser knows the IP address of a server, it needs a common language to communicate. On the web, that language is HTTP (HyperText Transfer Protocol) — or its secure version, HTTPS.

An HTTP request has a method that says what kind of action you want:

• GET — fetch a resource (load a webpage, get a list of products)

• POST — send new data to the server (submit a form, send a payment)

• PUT / PATCH — update existing data

• DELETE — remove data

The server then responds with an HTTP status code that tells you what happened:

• 200 OK — success, the data is here

• 201 Created — a new record was created

• 301 / 302 — the resource moved to a different URL

• 400 Bad Request — your request had an error

• 401 Unauthorized — you need to log in

• 403 Forbidden — you are not allowed to do this

• 404 Not Found — the resource does not exist

• 500 Internal Server Error — something went wrong on the server

HTTPS (the "S" stands for Secure) is HTTP with encryption added. Your browser and the server agree on a secret key, then all data sent between them is scrambled so nobody in the middle can read it. You can tell a site uses HTTPS by the padlock icon in your browser's address bar. Always use HTTPS for any app that handles personal data or payments.

Imagine Dawit's e-commerce website sells injera-making machines. Most days he gets 200 visitors, but on the day of the Great Ethiopian Run in Addis Ababa his site goes viral and suddenly 50,000 people try to visit at once.

A single server would collapse under that load. This is where load balancers come in.

A load balancer sits in front of multiple servers. When a request arrives, it decides which server is least busy and forwards the request there. The effect is that your app can handle far more traffic than any single server could manage alone — and if one server crashes, the load balancer automatically stops sending traffic to it and routes requests to the remaining healthy servers instead.

Load balancers are a core part of how every major web service — TeleBirr, CBE Mobile Banking, Zoom, and thousands of others — stays online during peak demand.

All major cloud providers (AWS, Google Cloud, AletCloud) offer managed load balancers that you can set up in minutes without needing to configure the hardware yourself.

Modern apps are not monolithic slabs of code. They are made of many separate services — a frontend (what you see), a backend (business logic), a database, a payment processor, an SMS service — all talking to each other over the network using APIs.

An API (Application Programming Interface) is a defined set of rules that says: "if you send me a request in this format, I will send you back a response in that format."

For example, when Almaz uses the CBE Mobile app to check her balance, the app's frontend sends an HTTP GET request to the bank's API:

GET https://api.combanketh.et/v1/accounts/balance

Authorization: Bearer <token>

The bank's backend server receives the request, checks the database, and responds with her balance as structured data (usually JSON format):

{ "account": "1000123456", "balance": 15420.50, "currency": "ETB" }

The app then displays that number on screen. The user never sees the API call — they just see "Balance: 15,420.50 ETB".

APIs are why a developer in Addis Ababa can build an app that integrates TeleBirr payments, Google Maps locations, and Cohere AI — each is a separate service with its own API that the app calls over the network.