Synchronous

In a synchronous model, operations happen one after another in a strict order. When your code calls a function, the program holds at that line until the function returns. The next statement does not run a microsecond early. This is the default way most people first learn to write code: read a file, then print its contents, then exit.

The defining property is blocking. The thread that made the call cannot do anything else while it waits. If you call a database query that takes 40 milliseconds, that thread sits idle for those 40 milliseconds and only continues once the rows come back.

Synchronous is about ordering and waiting, not about speed. A synchronous call can be fast (reading from memory in nanoseconds) or slow (a network request to another continent taking 300 milliseconds). What makes it synchronous is that the caller does not move on until it has the answer.

When a function is called synchronously, the runtime pushes a frame onto the call stack with the arguments and a return address. The function runs to completion, places its return value where the caller expects it, and pops its frame off the stack. Control flows straight back to the line after the call. This is the normal call-and-return mechanism every CPU and language supports natively.

For an operation that involves waiting, such as disk or network I/O, a blocking synchronous call typically asks the operating system for the data and then puts the thread to sleep. The OS scheduler parks that thread and gives the CPU to other threads. When the data arrives, the OS marks the thread runnable again and it picks up right where it left off. The CPU is not wasted, but that specific thread is stuck until the result is ready.

This is why synchronous I/O scales by adding threads. A classic synchronous web server like Apache with the prefork module dedicates one process or thread per connection. If 200 requests are each waiting on a slow database, you need at least 200 threads, and each thread costs memory (often 1 to 8 MB of stack). Asynchronous servers exist precisely to avoid that one-thread-per-wait cost.

Reach for synchronous code first because it is far easier to read, write, and debug. The execution order matches the source order top to bottom. Stack traces point straight at the failing line. There are no callbacks, promises, or event loops to reason about, and errors propagate cleanly with normal try and catch.

The cost is throughput under concurrency. A thread blocked on a synchronous call does no useful work while it waits, so handling many slow operations at once means holding many threads, which burns memory and hits context-switching limits. If you make ten independent API calls one after another and each takes 100 milliseconds, the total is 1000 milliseconds, whereas issuing them concurrently could finish in roughly 100.

A good rule: use synchronous for CPU-bound work, short local operations, scripts, and any logic where the next step genuinely needs the previous result. Switch to asynchronous or concurrent patterns for I/O-bound work at scale, such as a server fielding thousands of simultaneous requests that each wait on a network or database.

Picture a checkout endpoint that charges a card, writes an order row, and sends a confirmation email, in that order, synchronously. Charging the card takes 250 milliseconds, the database write 15 milliseconds, and the email send 400 milliseconds. The user stares at a spinner for about 665 milliseconds because each step waits for the one before it, even though the email has nothing to do with whether the page can load.

The fix is not always to make everything asynchronous. Keep the parts that must be ordered synchronous: you cannot write the order before the charge succeeds, and you should not confirm a charge that failed. But the email does not need to block the response. Many systems hand the email off to a background queue and return to the user as soon as the order is saved, cutting the perceived wait to about 265 milliseconds.

That pattern, synchronous where ordering and correctness demand it and asynchronous where the caller does not need the result, is how most production systems are actually built. Synchronous is not the slow choice or the wrong choice; it is the simple, correct default that you deviate from deliberately when waiting becomes the bottleneck.