What this gives us
- Simple request path
- Minimal infrastructure
- Easy local development
- Low operational cost
Lesson 1 · Foundation
The client calls the application server directly.
The client knows the Catalog Service address and sends GET /api/products straight to it. There is no proxy, gateway, or load balancer between them.
Interactive architecture lab
Send one request directly to one server.
Start the lesson, execute the request, and watch which server receives it.
Known destination
http://localhost:6212/api/products
Start the lesson, then execute the direct request.
Execute a request to inspect the original response.
Execute a request to inspect the response headers.
Direct HTTP
:6212
No intermediary
Port
:6212
Request log · time / method / URL
Start the lesson to see the Catalog Service request log.
What happened?
Follow the request through the server.
The diagram shows the network path. This trace reveals the work that happens along it.
- 1Client opened a connectionDirectly to
localhost:6212 - 2
GET /api/productswas sent directlyNo intermediary inspected or forwarded it - 3Express matched the endpointThe application selected its products handler
- 4Catalog Service queried PostgreSQLThe service performed its data-access work
- 5catalogService1 returned JSONThe response travelled back on the same path
What this teaches
Simple to start. Harder to scale.
Suppose you create a simple server and host it on the internet.
A client can interact with your service using its hostname or IP address, and the incoming requests are handled directly by your server.
This is a simple and fast setup, but it puts more responsibility on the server. Along with your application’s business logic, the server may also handle tasks such as:
- SSL/TLS terminationThe server completes the HTTPS handshake and turns encrypted traffic into a request the application can process.
- Encryption and decryptionData is converted between readable form and a protected form while it travels across the network.
- Compression and decompressionPayloads are made smaller before transfer and expanded again when received.
- Connection handlingThe server opens, maintains, reuses, and closes network connections from clients.
For low traffic, this usually isn't a problem. Even a standard server can comfortably handle hundreds of requests depending on the workload.
So while this setup works well for small applications, it becomes harder to scale and maintain as traffic grows.
What becomes a problem
- Single point of failure
- Limited capacity
- No automatic failover
- Client knows the server address
- Scaling exposes more server addresses