Scalability is not ultimately limited by the bitcoin network, but also by connections/users. Bitcoin-core I think is becoming less and less used by companies just because it is so heavy and not scalable. It really tops out at only a few 1000 connections, even raising the file limit from 1024 (default for most linux systems) to higher and higher numbers doesn't help anymore.
It intentionally doesn't support more concurrent connections at this time. While it would be easy to make it do so I am not aware of a single use case for which supporting more would make sense. Nothing of relevance to this thread should result in running many concurrent connections to the daemon. If you'd care to state an application, I'd be interested in hearing it.
(Considering that the entire network can only support on the other of 10tx per second, I am at a complete loss as to what aspect of customer invoicing would require you to run a thousand concurrent connections to a single Bitcoin daemon.)
This causes another problem which we have seen time and time again, that if you do a withdraw and don't say it could take 12-24 hours to process, and it doesn't show up on the network in a few seconds. The idea that company is now a scammer, is what consumes the mind. So now you are not able to use the the programical instant withdraw that only the bitcoin network as a bootstrap startup without risking your reputation.
Can you retry saying this, I'm unable to parse your English.
I believe we are failing as a community in many ways about this, I recommend 3rd party apis because that is the only solution currently. There are no other full nodes that can handle this unless you enter the enterprise stage.
You've failed to state an actual reason here. Can you try to clearly specify particular problems with concrete details. Simply saying "it doesn't scale" is not helpful.