I would definitely recommend still unmounting (ejecting) the drive before disconnecting it, but you can actually make it so that writes are not buffered.
You do this by changing the mount options when mounting the external drive. You want to enable the "noasync" and "sync" options. This means that both data and metadata operations happen synchronously - i.e. the operating system waits for a write operation to complete before it lets the application continue.
Note that this comes with drawbacks - and still isn't a guarantee against data loss:
The synchronous nature of things means that you will experience some slowdown in the programs writing to the disk drive. For backup purposes that probably isn't so bad. The slowdown is less severe with SSDs than with traditional hard drives, but it is still there.
The writes being synchronous also mean that they're serialized (i.e. performed in order). If you have a program that is often writing to the same location with different data (for example a program updating a counter on disk) - this could lead to more writes to the actual disk. With asynchronous writes, a newer write could cancel an older, not-yet-performed write to the same location. This effectively speeds things up and reduces the number of writes to the disk. For SSDs this is the same as reducing wear of the drive.
Finally, you're still not guaranteed against data loss yet - for two main reasons:
A write might still be taking place or about to take to place when you're disconnecting the drive. If the program doing the write is not written to be resilient against "disconnections", you might end up in a situation where the application performed only part of a scheduled number of writes - and when the data is read in again, this creates an illegal state in the program. I.e. writes A and B depend on each other, and you're not supposed to have a situation with A performed without B or vice versa.
Programs do generally not take care to avoid such situations. You'll find that sort of support in for example many database systems - even in "small" systems such as SQLite, which thankfully is being used as a backing storage for many apps today.
The second main reason is that often the drives themselves contain a write buffer. Historically, cheaper consumer drives would often just stop working the instant power is lost - and the data in the write buffer would be lost. This would effectively negate the efforts you have made to ensure the operating system does not have a data buffer.
Traditionally this would be avoided on server systems by having a disk controller with a battery backed write cache - ensuring that as long as power was restored within the next 24-48 hours, the uncompleted writes would be performed when power is restored.
On SSDs today many will come with a supercapacitor (you can think of this as a kind of self-charging battery) that ensures that the disk always have power to complete the writes in progress when power is lost. However, some do not - and consumers brands usually do not advertise whether or not they have this feature.
