The obvious answer is, send large quantities of data in small packets, by defining a protocol for how to transfer it.
How to e.g. split 20 KB of data into packets containing e.g. 32 bytes each in order to transmit it is up to you.
Then on the MCU end you reverse the process, combine the data from small packets into one large blob of data before doing anything with it, or store it somewhere you want 32 bytes at a time.
It is likely that no such protocol yet exits so you may have to roll your own, but you may use something similar as an example.
Commonly protocols that have done similar things have existed for decades in the era where people transferred files over modems with acoustic coupling to a landline telephone handset.
Commonly packets might have some control information in addition to just sending data, such as this is now a start of tranfer of something with some total size, a length how much data this packt contains, a CRC or checksum to protect the data from errors, and maybe a counter to indicate packet sequence number so you know if some packet was lost and may need to be restarted or retransmitted. Commonly such a protocol would also have some response packets that define you got packet number X so transmit next packet, or that there was an error and request to retransmit, or some timeouts that retransmit something in case of the ACK/NAK packet was lost.
That's already very complex but feel free to make it as simple as possible, like just sending data packets with some flags that this is the start of data packet for a new thing, continuation packets, and final packet, so packets for short data could have these start and end flags both set and then you have long packets which signal that there will be more data after this and this is a continuation for previous packet. Again, some counters may be beneficial, like each small packet containing ID that this is a packet number X of transferring any binary blob number Y so again you can detect if packets were lost so nothing gets corrupted.
