HTTP Concurrency Model

// Dependency: spring-boot-starter-web  (embeds Tomcat)
// Default thread pool: up to 200 threads (server.tomcat.threads.max)

@RestController
@RequestMapping("/api")
public class MessageController {

    private final MessageService service;

    public MessageController(MessageService service) {
        this.service = service;
    }

    // Tomcat picks a thread from its pool and runs this method on it.
    // The thread is OCCUPIED until MessageController returns.
    // During service.findById() — waiting on the database — the thread
    // just sits there, blocked. It cannot serve other requests.
    // At 200 concurrent slow DB calls, the 201st request queues.
    @GetMapping("/messages/{id}")
    public ResponseEntity<Message> getMessage(@PathVariable Long id) {
        Message msg = service.findById(id);  // thread BLOCKS here
        return ResponseEntity.ok(msg);
    }
}

// Dependency: spring-boot-starter-webflux  (embeds Netty)
// Event loop threads: 2 × CPU cores  — these must NEVER block

@RestController
@RequestMapping("/api")
public class MessageController {

    private final ReactiveMessageService service;

    // Returns Mono<T> — a promise of a single future value.
    // The event loop thread is freed immediately to handle other requests.
    // When the DB responds, Netty picks up the continuation.
    // High throughput — but you must think in reactive streams.
    @GetMapping("/messages/{id}")
    public Mono<ResponseEntity<Message>> getMessage(@PathVariable Long id) {
        return service.findById(id)              // non-blocking DB call
            .map(ResponseEntity::ok)             // transform when value arrives
            .defaultIfEmpty(ResponseEntity.notFound().build());
    }

    // Flux<T> — a stream of multiple values over time
    @GetMapping("/messages")
    public Flux<Message> streamMessages() {
        return service.streamAll();  // emits items as they arrive
    }

    // WARNING: never call blocking code inside a Mono/Flux chain.
    // service.findById() must itself return a Mono — all the way down
    // to the DB driver (R2DBC, not JDBC). One blocking call stalls
    // the entire event loop thread and kills throughput.
}

// Gin wraps net/http. Go's http.Server spawns one goroutine per request.
// Goroutines start at ~2KB of stack (grows on demand, up to ~1GB).
// Millions of goroutines can coexist — no pool size to tune.

type MessageHandler struct {
    service MessageService
}

// This handler runs inside its own goroutine for every request.
// The code reads top-to-bottom like blocking code.
// When FindByID waits on the DB, the goroutine is parked —
// but its OS thread immediately picks up another runnable goroutine.
// No callbacks. No Mono chains. No reactive operators.
func (h *MessageHandler) GetMessage(c *gin.Context) {
    id := c.Param("id")

    msg, err := h.service.FindByID(c.Request.Context(), id)
    if err != nil {
        c.JSON(http.StatusNotFound, gin.H{"error": "not found"})
        return
    }
    c.JSON(http.StatusOK, msg)
}

func main() {
    service := NewMessageService()
    handler := &MessageHandler{service: service}

    r := gin.Default()
    r.GET("/api/messages/:id", handler.GetMessage)
    // Every incoming GET /api/messages/:id → new goroutine → GetMessage
    r.Run(":8080")
}