In addition to what LPRF has indicated. My experience is with vehicle odometers where both requirements must be met; not to exceed the EEPROM NV write cycles and not to lose mileage data. We manage the data on RAM initially, and periodically write this data at a lower cycles on EEPROM and before going into sleep or completely off-power. Now, this poses another problem; anytime you have data being caches on RAM and EEPROM, there is the need to perform some redundency checks with segment checksum. Not knowning much about your problem and timing; here are the steps I would apply;
(1) Find out the worst case for fastest & slowest incoming of your data. (2) Is your device going into complete sleep between data logging? (3) Is this sleep using power mode where RAM is unpredictable? (4) Is your data needs to be timestamped? (5) Do you care only about different data or do you have to log same data.
Once you have these answer; you would want to keep your data on RAM as "reasonable" as possible and cach it on EEPROM at periodic rate or some event (example; before going to sleep). The "reasonable" is depending on how much data loss you can tolerate? ie. if every message needs to be logged; then you have no choice. But if you can filter duplicate data out with some time-stamp/ count then you can do some pretty good design.
Hope this helps