Non-blocking I/O lets an OS thread do other work while an I/O operation is pending. In an Actix Web server, that can mean processing other tasks while waiting for network activity. It is distinct from multithreading: Actix also starts worker threads for parallelism, with a separate application instance on each thread. section 3.1.2 section 3.3
This matters for I/O-heavy web services. A request may wait on network communication or database access; an asynchronous design avoids making that wait the only work available to a thread. Actix Web handles HTTP requests, and SQLx provides asynchronous database connections to PostgreSQL. Both network and database access are chosen to support asynchronous I/O. section 1.3.1 section 1.3.2 section 1.2.2
An asynchronous Actix handler
A GET route for /health points to an async handler: `pub async fn health_check_handler() -> impl Responder { HttpResponse::Ok().json("Hello, EzyTutors is alive and kicking") }`. The signature shows where an asynchronous handler fits in request routing. This particular response does not demonstrate an I/O wait. section 3.1.2
Follow a request from the listening HTTP server through its application route to a handler, then distinguish the two concurrency mechanisms: worker threads provide parallelism; async I/O allows other tasks to run during an I/O wait on one thread. Actix uses an async runtime based on Tokio. section 3.3
