Is a ticketing system a good backend project to learn with?

Yes, especially if you make it a concert or event booking system. The most useful early challenge is preventing two people from reserving the same seat at once. That gets you into database transactions, concurrency, and clear failure handling before you worry about big traffic targets.

First decide what kind of tickets you mean. A support-ticket tracker mostly teaches workflows, permissions, search, and notifications. Event tickets bring in inventory, temporary reservations, payment states, and the risk of overselling. They’re both worthwhile, but they’re different projects.

That’s a fine long-term target, but don’t design around a number until you can measure a working version. Start with the core flow, then load-test it and see what slows down. Be specific about what you’re measuring too: requests per second and completed bookings per second aren’t the same thing.

Keep the first version small: events, seats or ticket inventory, reservations, and booking status. Make reservation expiry and duplicate booking behavior explicit. Once that works reliably, add tests for simultaneous attempts, then look at caching or queues only if your measurements show a need.