How to make PostgreSQL replication and load balancing take into account write load, not read load?

Question

PostgreSQL

Hi all.
It is necessary to raise the base on k8s (but this is not important), the main task of which is recording.
In the near, near future, 16k writes per second and 1k reads per minute are planned.
I did not find any schemes for distributing the load on the record, except for Warm Standby, which will save the situation in the event of a break, but did not find unloading and distributing the record among several. In theory, something like BDR is possible , but I don’t know how fast and expedient it is to use the concept of a replica for load distribution .. probably not ...
Give me a couple of ideas, how is it better?
Does anyone have a good recipe that works...
Many will probably advise using queues - and they will be right - yes, it is already in development, but it is necessary as always yesterday. And message queues will be "tomorrow in a year", and they will not fully solve the problem, but will only dilute the load on "hayah".
Other bases are not considered - I know that the same mongo can be divided into X nodes without shamanic dances with a tambourine ... but not an option for us.
Thank you!

Answer 1

Attention to the question: why?
100 writes per second and 5 reads per minute is nothing.
Write 10,000 records per second - so what? There is no problem to keep it on one piece of iron and this is in the usual OLTP, and not 99% write / 1% read like you have.
Take adequate disks, throw the docker to hell. And for hot standby, you do not need to scale the recording. Simple and reliable streaming replica.
Thanks, good joke.
Just in case: you remember that no replication for record scaling can help? If each host must contain a copy of the data, then it must write all the data. For record scaling, sharding is the right word. Only it's not about hundreds of transaction records.