Moving past TCP in the data center, part 1

> Is it really true, that all or at least most traffic in a DC is some kind of RPC or request/reply system?

In my experience (as a Google SRE), yes, at least for the way that Google tends to architect its services, anyway.

> I am an application developer. When I request data from any kind of information service - for example a database - I want the data to be complete and reliable. And to me that is far more important than to have some data faster. The nice thing about a TCP session is: as long as the session stays connected and error free it doesn't matter, if I retrieve 100 bytes or 100,000 bytes or 100,000,000 bytes, TCP guarantees, that I get all the data in the correct order.

For a typical CRUD app, you're generally dealing with one tuple at a time, or at most a few dozen (e.g. for search results).

Yes, we do have batch jobs that look at many (or all) tuples and manipulate them in some way. No, those jobs are not top priority. Top priority is responding to incoming HTTP requests in a timely fashion. If that means throwing away hours of batch work because live serving needs the machine, so be it.

> On the other hand I have to work with market data feeds of different stock exchanges like NYSE or Xetra. They use UDP multicast to distribute the information. Dealing with this unreliable transmissions and recovering from lost packets is something you really don't want to do.

Sounds like you're in finance. This is a very different sort of industry to tech - your top priority is probably some variation of figuring out which way the market is moving, not responding to incoming HTTP. So things are going to look different on your side of the fence. That does not mean the article is wrong. It just doesn't apply to your particular situation.