I'd ask this backwards: Why bother with a homegrown solution when syslog exists and gets the job done?

A home-grown solution takes at least a couple weeks to stabilize, likely much longer before the last bugs are ironed out. Syslog takes about a day to beat into shape.

Any ad hoc scheme you come up with that uses a real backend store will be better than syslog.

You know better than that.

Shipping messages reliably is a surprisingly tedious problem. First you realize you need a disk-spool. Then you realize that spool should be size-capped anyhow. Eventually your boss says you need a network topology more complex than A->B for some idiotic but inevitable reason.

And then next month you run into some redis limitation and realize some kind of datastore abstraction would have been a better idea to begin with. Hmm, perhaps dump to plain-text files until we figure that one out?

See the pattern here?

At the end you have reinvented syslog. Sure, yours may be nicer or at least different.

But that's a whole lot of work to avoid something that, despite all its warts, already works.