
Courier: Dropbox migration to gRPC - jparise
https://blogs.dropbox.com/tech/2019/01/courier-dropbox-migration-to-grpc/
======
LiamPa
LIFO, I see its being used here but I still don’t understand why you would?

~~~
SaveTheRbtz
Our train of thought goes like that:

* in non overloaded case LIFO/FIFO make no difference[1].

* in an overloaded case LIFO has better reliability properties, e.g. no standing queue and therefore faster recovery times.

There are alternative approaches there to the problem: Facebook queues switch
from FIFO to LIFO when overload is detected[2]. Airbnb uses the same
approach[3]. We tend to stick with a simpler way of using LIFO by default.

[1] Given that one does not care about message ordering. If order matters, as
mentioned in the post, one can use CoDel or use LIFO only between different
connections, maintaining FIFO within each connection.

[2]
[https://queue.acm.org/detail.cfm?id=2839461](https://queue.acm.org/detail.cfm?id=2839461)

[3] [https://medium.com/airbnb-engineering/building-services-
at-a...](https://medium.com/airbnb-engineering/building-services-at-airbnb-
part-3-ac6d4972fc2d)

~~~
LiamPa
Thanks for the response.

> faster recovery times

Is this because of client timeouts or am I missing something?

~~~
SaveTheRbtz
There is a good discussion of LIFO queue behaviours on the corresponding
reddit thread[1], featuring the Google's SRE book, Van Jacobson quotes, and
real world examples.

[1]
[https://www.reddit.com/r/programming/comments/adwhk3/courier...](https://www.reddit.com/r/programming/comments/adwhk3/courier_dropbox_migration_to_grpc/edlhn8c/)

