Problem caused by unconfirmed transaction chains I want to build a service that requires sending many small bitcoin transactions to multiple wallets (like a faucet). 

Since the transactions are small, the fees have to be kept small as well so it takes a while for them to be confirmed. 

The system would need to send many transactions, which naturally creates long chains of unconfirmed transactions. If I understand it correctly, after 25 unconfirmed transactions the network starts rejecting new ones, and the system is basically stuck until the previous ones gets confirmed. 

This limits the throughput of such a system to 25 transactions per confirmation time (which is at least a few hours given the low fees), making it completely unscalable.  

Given the above, is there a way to build a (somewhat) scalable service that can send many small transactions? (without having to manage many wallets)
A few simple ideas get around the unconfirmed-tx-chain-limit you're running into:

Start with more UTXOs. Each UTXO can be used to create &lt;25 unconfirmed child transactions. So if you need to make n payments, you'll need at least n/25 UTXOs to do so using this method.

However, you can definitely do this in a more cost-effective manner. As Murch mentioned, batch payments describe the method of creating a single transaction with many outputs. So instead of paying one customer per transaction, you can pay many customers per transaction. 

Another option is to use the lightning network to send your payments. Lightning transactions are extremely cheap, and fast. If you are regularly sending small payments, I'd encourage you to consider this option.