ACINQ has some good blogs about their approach

I asked a similar question a while ago and got some great answers: #181315

A "big boy" Lightning Network node needs to be highly available. It needs to be able to send multiple (maybe hundreds!) of payments in parallel, create invoices frequently and wait for them to be paid. It also needs to minimize downtime when upgrading or maintaining the node. Some things you may try:

Postgres: You might want to configure postgres as the backend database. This will allow you to cut your node's startup time considerably. Upgrading your node for example might only take a few seconds when shutting down the old version of LND and starting up the new version right after.

Multiple nodes making invoices. You might have multiple nodes generating invoices in parallel, each connected to your main node via a "trusted" channel. This trusted channel does not exist on chain, but is included as a hop hint in each invoice. This lets you scale up the number of nodes that generate invoices, but all funds land in your main node. With such a setup you could also theoretically have to "main" nodes. The "invoicing nodes" then don't need to hold any funds themselves, meaning they can run under different security assumptions.

Multiple nodes making payments. Similar to invoicing, pathfinding and attempting payments may consume significant resources. By having separate nodes that attempt payments, your main node does not need to stay synced to the graph, and can focus on routing.

Also important, bigger nodes need sophisticated channel management. You might notice that well-managed big exchanges or payment processors often don't have a lot of channels. Bitpay only has 13, Binance, despite 200 BTC in capacity, only has 72. Compare that with less well-managed nodes like Bitfinex, which has close to 1000 channels and it damn hard to reach. Ideally, you'll want a few channels to well-connected peers, which you will keep empty or full, depending on your use case. Submarine swaps are a great way to manage these channels, it keeps the channels alive for a long time, keeps your peers happy, your fees low and makes payments reliable. If you have 1000 channels, and only 500 of them have inbound capacity, a payer will take significantly longer finding a route to you than if you have 10 channels, and 5 of them have inbound.