Why a recurring school run is not just twelve bookings

When we built recurring trips for Topsy Teens, the obvious approach was the one already in the platform: take a booking, repeat it N times, create all the trips at once.

It works for a short series. For a school term it is wrong in three separate ways, and understanding why is a decent illustration of how a feature earns its complexity.

Problem one: the money

A term is roughly sixty school runs. Creating them all at booking time means reserving sixty fares before the child has taken a single trip. No parent should have a term of travel committed on a Monday evening in September.

Problem two: change

Parents change things. The pickup time moves by ten minutes. The school changes its finishing time. A child stops going on Wednesdays.

If sixty trips already exist, every change means unpicking sixty rows. If the arrangement is the record and the trips are generated from it, a change applies to everything not yet created and the problem disappears.

Problem three: the pattern itself

The existing recurrence supported a uniform interval repeated N times: daily, or weekly, up to twelve. A school run is not that. It is Monday to Friday and not Saturday, which cannot be expressed as one interval.

What we built instead

A standing arrangement holding the days of the week, the times, the two places and a start and end date. A scheduled job then materialises the next few days of trips on a rolling basis.

Each generated trip carries a key derived from the arrangement, the date and the leg, and the booking layer treats that key as an idempotency key. Running the generator twice in a day therefore books nothing new. That property is what makes a rolling generator safe: it can be re-run after a partial failure without double-booking a child.

The general shape

When something repeats on a real-world schedule rather than a mathematical interval, store the rule and generate from it. Storing the generated instances instead feels simpler for about a week.