The Future of Asynchronous IO in Python

You can get those with a straight library without introducing the complexity of message-passing, RPCs, and distributed systems.

(I'm a big fan of SOAs/microservices for companies that operate at Google-scale. Most companies do not, and for the rest of us - plain old libraries are very underrated. You can always slap an RPC layer or message broker on top of a library's API, but there's no reason to pay that cost until you need to. The real reason to break things up into microservices is when you run out of RAM on the box, or alternatively when you want better cache hit rates by focusing the processor on a small amount of code. You typically don't get there until you're serving thousands of QPS against a data set in the terabytes.)

>A system which serves millions of users spans multiple machines. It's much easier to scale and evolve your stack if you're keeping it decoupled.

It can be much harder. Let's say that you have a zipcodeaddress conversion library and you're deciding whether to use it within the web stack (option A) or to create an additional service with a REST API on a separate machine (option B). Microservices!

Option A means that it scales with your web stack. If you have 5 application servers today behind a load balancer and your load doubles then tomorrow you will need 10.

Option B means an entirely new set of servers. Not only do you still need those 5 application servers, you need an entirely new server for handling zipcodeaddress translation. Let's say it's maxed out.

What happens when your load doubles then?

Well, you'll still need to scale up those 5 application servers running behind a load balancer, but you ALSO need an entirely new load balancer and two servers behind it for the zipcodeaddress translation service.

>Different languages/services have to talk to each other somehow and at some point.

This doesn't mean that you need for them to talk over a network layer.

> Article suggests that a high performance framework is implemented > where notification of a unavailability will be propagated "before > real user tried to execute a request" (which would have 50% probability > of happening if number of heartbeats per second would be equal to number > of requests per second the service serves, ha ha).

Yes and no. Sometimes there is a dependency that is used only on 1% of requests, or even 0.1% of requests. And that's thing thats hard to track by 50x error codes, because they are really rare.

But anyway it's not "fully designed feature", just a vision of what potentially can be done. So it's not going to be a stumbling-block for implementation.

> Also from the Article we can learn that sending a 304 with content does not work as expected (!?)

Sending 304 works as expected. Passing arbitrary status code with arbitrary headers with arbitrary body from the application to a framework doesn't work as expected.

> Not only that, but there should be only one connection to database, > through all traffic will go. Pulling that up through a network switch > connected to a server with multiple cables, or pushing all that through > a single TCP connection, with a foot note that advises against rewriting > it after a few years?

Not sure I understand your question well. But note that I'm speaking about Python. We have many python processes on the box anyway. Each of them has it's own connections to the downstreams (i.e. a database).

Then if we start writing asynchronous Python code, we need to send requests from multiple asynchronous tasks from each of the python process. I argue that it's more efficient to send requests from all tasks of a single process through a single downstream connection.

> Also, everything explained there should run in a single thread, > because surely it will be fast enough.

Sure, single I/O thread in C will outperform any python processing of that data. That's true for 99.9% use cases.

Sorry, English is not my native language. You can use "notes" in medium, to point me to the mistakes.

Do you have a link for description of how it works in QNX?