I believe the fee rate can be used to guide payments. Channels that do not have funds which may be used to forward transactions are disabled (lncli updatechanstatus), whereas I apply a fee rate discount to channels which have a lot of funds available on the local side (i.e., funds that may be used to forward transactions).
One strength of the lightning network is that channels can be used in both directions, possibly sending/receiving the channel capacity multiple times over the lifetime of the channel. As such, I apply a fee rate discount for bidirectional peers.
Fee rate, updated every few hours:
With a fee rate of F ppm (ppm = parts per million), it costs X / 1,000,000 * F sat to forward X sat (plus the base fee).
I have been running this node since mid 2018, and in the past couple of years I have learned a thing or two based on my experiences. This text is my attempt to share this knowledge with you. Although it is very easy to set up a node in the lightning network, it is a lot harder to attract incoming channels and forward a satisfactory number of transactions.
Inbound and outbound liquidity
If you want to send funds from your node to any other node in the lightning network, you need to have outbound liquidity. This can easily be achieved by just opening channels to other nodes, so that you can send funds to those nodes. You may also use your directly connected peers to route your funds towards your destination. However, if you want to receive funds, you need to have inbound liquidity.
As inbound liquidity is made out of funds that belong to someone else, you need to convince someone else to open a channel to your node. Additionally, if you send funds to other nodes, these funds become inbound liquidity.
You may ask people to open channels to your node (some people organize via Reddit etc. to create triangles/rings of channels between their nodes). Nowadays, you can also buy liquidity from specific peers (lnbig.com, yalls) or use services like loop to acquire inbound liquidity.
Based on my experience it helps to offer a node that is attractive for others. Given enough time (patience is key!), assuming that your node is stable and has good channels to many good peers, other people will find your node and might be interested in opening channels to it. I believe the criteria listed at terminal.lightning.engineering are helpful in creating an attractive node.
The lightning network is capable of routing microtransactions for low fees, which is why even a very small channel may be helpful. However, smaller channels still need to be opened (and, eventually, closed) via on-chain transactions. The fees you need to pay for these transactions are not proportional to the channel size. As an example, a transaction opening a 10,000,000 sat channel might cost the same as a transaction opening a 10,000 sat channel.
As the node operator, you usually want to recoup those on-chain fees via forwarding (off-chain) fees. As such, for smaller channels, you might need to forward the funds back and forth multiple times before earning back the on-chain fees you spent for opening the channel. This also means that you would rely on your peer to send the channel funds back to you, or that you would need to pay for rebalance transactions.
For larger channels it might suffice to just send a fraction of the funds, giving you the option to configure a lower fee rate without exposing yourself to financial risk. Additionally, larger channels allow you to route large transactions (earning you lots of fees), which is not possible with smaller channels.
I always enjoy seeing my node forward (lots of) microtransactions, but based on my experience only larger payments help recoup the on-chain fees. Customers of exchanges like Bitfinex tend to send/receive transactions with amounts higher than 1M sat. Each of these transactions brings in a lot of fees, but also requires your node to have a lot of inbound and outbound liquidity.
In theory a channel in the lightning network can be used without limit, sending funds back and forth countless times. If you have a channel that behaves like this, over time you will earn enough routing fees to recoup your costs. However, in reality, most channels do not show this perfect behaviour.
Some nodes are known to be liquidity drains, which means that they mostly receive funds. As an example, some merchant may loop out to convert outbound liquidity to inbound liquidity and off-chain funds (so that the merchant can receive more funds off-chain and can cash out on-chain). This process works by sending funds from the merchant to the LOOP node in the lightning network. Although there is also a reverse process called loop in, in practice the LOOP node rarely sends funds.
With drain nodes like LOOP (and others) there is always the risk that the funds are quickly forwarded to the other side of the channel, and then the channel is closed. In this scenario, you only earn fees for forwarding 100% of the funds once, and have to pay both the channel open and channel close transaction on-chain fees. On top of that, you lose inbound liquidity, which might lead to further costs/troubles.
Based on my experience it is a good idea to charge high fees, especially for nodes with unknown behaviour, or those with known drain behaviour. You can always adjust fees if you learn more about how a channel behaves, but raising fees after you already routed your funds to the other side is not helpful. It might be a good idea to have a look at the fee rates other nodes charge to send to some node before you open a channel to that node!
In a perfect world, you would never have to close a channel as long as you do not need on-chain access to your funds. In reality, there are several situations in which channels are closed.
Both the lightning network specification and the various software implementations are evolving. Nothing is perfect, which is why bugs surface from time to time. Based on my experience there is a very low risk that you lose access to your funds. However, there is a higher risk of channels being closed without it being intentional. This may, for example, happen due to spikes in on-chain fees or programming errors.
Node operators may need to close channel to move the funds to another (new?) node. Node operators may want to close smaller channels, for the reasons outlined above. A channel might not be good enough, making operators want to close the channel and invest the funds elsewhere.
Of course, you should make sure that your peer does not have a bad reputation for closing channels early and often. In addition, even for peers with a good reputation, you should always assume that any channel may be closed sooner than later. As such, make sure that you charge appropriate fees!
Number of forwarded transactions
The lightning network is able to forward several transactions per second (per node!). However, in my experience I have rarely seen more than one transaction per hour on my node. Please do not assume that, once you opened a few channels, your node automatically starts to forward lots of transactions.
More realistically, you might see a few smaller transactions per day, and a larger transaction every couple of days. This, obviously, depends on a lot of factors, including your node's liquidity/reputation/availability, and of course also the users/services at the source and target nodes of the transactions.With this in mind, you should plan accordingly. Most of your funds will not move most of the time, which is why all associated costs and risks should be offset by those few (larger?) transactions you see over the (short?) lifetime of the channel. If you have outbound liquidity to an exchange, you might need to wait for the market conditions to change so that users want to sell coins on the exchange. As soon as this happens, when you forward their funds to the exchange, you should charge fees that also take into account the risk (your node might be hacked?) and work you invested up front: you paid to open the channel in time, you made sure to attract inbound liquidity, ...
In my experience users are willing to pay seemingly high fee rates, as long as you provide the service they need: near instant transactions to the target of their choice.
Monitoring and tool support
If you run a routing node, you need to understand how the node is doing, and if there is anything that needs to be fixed.
Aside from any manual monitoring and tweaking, you should also make sure that certain changes are performed automatically. This could, for example, be disabling your side of a channel if you do not have any outbound liquidity, or adjusting the fee rate, or reconnecting to peers with inactive channels.