Fee estimation in a Bitcoin wallet is a user experience problem as much as a technical one. Users see a transaction stuck for hours and blame the wallet, regardless of what caused the delay.
When you need Bitcoin data in your application, you have two fundamental options: query a node's JSON-RPC API directly, or use an indexed API built on top of the blockchain data.
Bitcoin mempool fees are not predictable. During normal periods, a 10 sat/vB transaction confirms in minutes. During Ordinals inscriptions, market volatility, or halving events, the same rate may sit unconfirmed for hours.
Every time you deploy a new Bitcoin indexer - or migrate to a new server - you face the same problem: you need to process 880,000+ blocks from genesis to the current tip. How you do it determines whether this takes 6 hours or 6 days.
Bitcoin fee estimation is one of those problems that looks simple until you handle it in production. Simple sat/vB tiers break down quickly when you need to handle stuck transactions, vary by transaction type, or send hundreds of transactions efficiently.
Bitcoin has over 880,000 blocks. If you're building an indexer and need to backfill from genesis, your choice of transport protocol will determine whether that takes hours or weeks.
Bitcoin transaction fees confuse even experienced developers. They fluctuate wildly, different services give different estimates, and getting them wrong costs real money.