IMO not really - a valid architecture is nginx - haproxy - app servers
This depends a great deal on the architecture of your application server and traffic load. There are a lot of reasons that it is nicer to use a queue in front of your load balancer, rather than use queues in your application server, or worse, use the operating system queue.
You must have SSL termination, logging, load balancing, and queuing. You probably want to modify headers and interpret cookies as well.
HAProxy is a queue that feeds into a load balancer. Nginx is a buffer that feeds into a load balancer (IIRC).
One useful property that HAProxy can ensure is no more than 1 request going to a server at a time. I believe (but potentially incorrectly) that nginx will fail requests, rather than "queue" them, if it tries to ensure this property. HAProxy also historically had health checks for backend servers, while for nginx it was a paid premium feature.
I could be wrong about nginx not being able to queue. It has been a while.
For my mental model, nginx is the right choice for SSL termination, logging, request mangling, interpretation of cookies and loadbalancing based on request information (for example choosing haproxy instances based on a domain name). HAProxy is the right tool for queuing and load balancing to servers that will actually fulfill the request.
> For my mental model, nginx is the right choice for SSL termination, logging, request mangling, interpretation of cookies and loadbalancing based on request information (for example choosing haproxy instances based on a domain name).
HAProxy can do all that and IMO it also does it better.
Personally I chain HAProxy and nginx in reverse order: HAProxy exposed to the Internet, doing all the heavy lifting. (Multiple) nginx with minimal config as a static file server and FastCGI gateway behind HAProxy.
Nginx is used for serving some static error pages that live outside of the backend applications haproxy talks to (eg: "Customer domain not recognized"). There's some hacks to kind of make this work in haproxy but it's much simpler with an actual HTTP content server.
Nginx also works well as a caching proxy, and what's really cool with haproxy is it's easy to have most requests go directly to the application server (avoiding an unnecessary proxy hop), but just pattern match certain types -- eg regex match `.jpg$` -- to go through the nginx cache.
I've also used a similar technique to have per-domain custom images overriding specific URL paths (eg `/logo.png`), which was a really quick way to allow some customization of a multi-tenant application without having to make major code modifications to support it (only used for a tiny handful of customers).