The history of a film schedule matters as much as its current state. That one insight changed everything about how we built this.
At as our event store, running on PostgreSQL.
There are purpose-built event store options out there. The most prominent is , you'll know I'm not shy about having opinions on technical choices. This one follows the same spirit.
Are we confident in these architectural decisions? Yes. Did we make them carelessly? No. We looked at the trade-offs, understood what we were taking on, and made a deliberate call based on the domain in front of us. That's not the same as being reckless, it's just being an engineer.
But here's the thing: confident doesn't mean infallible. Event sourcing might bite us in ways we haven't anticipated yet. The projection rebuild story might get complicated at scale. Kurrent might start looking very attractive once the event volume grows. Schema evolution might turn out to be more painful than we've planned for. To be honest, that would be a wonderful problem to have - it'll mean that we have users using the product we've been building for some time.
If any of that happens, we won't be sorry for having made these choices. We'll be glad we made them deliberately, understood why they seemed right at the time, and are therefore in a much better position to understand why they stopped working. That's not failure. That's how a team gets better.
The only architectural decisions worth being sorry for are the ones made without thinking. These weren't.
The scheduling service is live as of this week. If you're building tools for film and TV production and want to chat architecture, or just want to compare notes on Marten in production, find us at
SOCIAL SHARE CARD GENERATOR