In the original definition of "design pattern", it is a solution to a problem that has been generalised across multiple domains. In fact, a "pattern" is not a pattern unless it has been independently discovered by multiple different groups (I believe the original suggestion was 3). The point of a design pattern is not that it is superior it is that it is common.
A design pattern is most assuredly not a best practice. In fact, it makes little sense to talk about a design pattern in isolation. It is a solution in a context. In some contexts it is appropriate and other contexts it is not appropriate. Design patterns used to have large preambles discussing the contexts where they were appropriate and where they were not.
The point about an anti-pattern is that it is surprising. It must be a common approach that looks like it should work, but it doesn't. It is definitely not a "bad practice", or an "I don't like that" practice, or even an "inappropriately applied pattern". It's a surprising result that you should be aware of that tends to catch people frequently.
Here is the first reference I know about discussing design patterns in software: https://c2.com/doc/oopsla87.html (Yes, the "87" refers to "1987"). People who have only read about design patterns in the last decade or two are almost certainly missing the original point (as seems to be sadly common with these kinds of things).
Take for example a load balancer that is configured to send traffic to the fastest server at the time. Makes sense, if a server is fast it has more available capacity to handle requests. But when the front end code fails the server short circuits, skipping all the expensive code as it unwinds the stack and returns a 5XX error, the load balancer that just sends to the fastest now sends ALL traffic to the failing node.
The antipattern is a feedback loop that is not measuring the right thing. In this case, they should be timing _successful_ calls to the front end.
A design pattern is most assuredly not a best practice. In fact, it makes little sense to talk about a design pattern in isolation. It is a solution in a context. In some contexts it is appropriate and other contexts it is not appropriate. Design patterns used to have large preambles discussing the contexts where they were appropriate and where they were not.
The point about an anti-pattern is that it is surprising. It must be a common approach that looks like it should work, but it doesn't. It is definitely not a "bad practice", or an "I don't like that" practice, or even an "inappropriately applied pattern". It's a surprising result that you should be aware of that tends to catch people frequently.
Here is the first reference I know about discussing design patterns in software: https://c2.com/doc/oopsla87.html (Yes, the "87" refers to "1987"). People who have only read about design patterns in the last decade or two are almost certainly missing the original point (as seems to be sadly common with these kinds of things).