I've built a system where I have 2 options - lifespawn of draft and lifespawn of published post (integer which marks days). If post is being published, exact date-time of publish is saved as `postmeta`, also lifespawn is added to that time and that value is saved to database as *expiration date-time*, same thing with draft (*a.k.a* when post is being saved). ---------- My current system is ran like this: - I've set up a server cron which runs at night in every 24h ---------- - All published posts are being queried - Publish date-time `metadata` is retrieved from database in `while` loop - That time is compared with current time in `if` statement - If time has passed, change post status to draft ---------- - All draft posts are being queried - Draft date-time `metadata` is retrieved from database in `while` loop - That time is compared with current time in `if` statement - If time has passed, delete post - All attached images to the post are also queried and deleted Im super worried that this system / server fails hard if posts amount is 10 000 - 15 000 or even few thousand. It's important that posts (especially published) that has exceeded the time, are taken down. **What other options do I have?** I've search for a working solution which could handle huge amount of posts and I've searched it for a long time - over 6 months while I've developed my site. ---------- **Ideas:** - Trigger the date-time *"check"* for *certain amount of older posts* in random queries that users do anyway? - longer loading times for users.. - Trigger the date-time *"check"* if single-post is being visited and do it one-by-one? - queries still retrieve and echo posts if people are quering it in exact same time which leads to 404s and disappointment. - Somehow split all posts and do it in chunks? - I could use `'offset'` to split posts to groups and do it in smaller chunks but it doesn't work if `page_per_page` is set to -1