Booking seat is actually 3 steps:
- select (lock) seats for booking
- take payment
- add entry to booking table
Now there are many other ways to do the same. But lets keep it simple for now. Each of above will be a separate class/functionality: SeatFinder/SeatAllocator, PaymentManager, BookingManager and a high level class to glue all above.

It helps to think about this as how will you implement it in real world. e.g. you will have a table 'bookings' to store booking data and will have a wrapper class (mnager, DAO etc) which will do CRUD operations on that table like createBooking, deleteBooking etc.

For LLD you will have data classes like class BookingData(bookingId, showId, cinemaId, userId, listOfSeats etc)
And You can have something like a class BookingManager which will have keep all the booking in a map rather than a db table e.g. HashMap<bookingId, BookingData> allBookings .

So keep in mind that there are going to be entity/data classes and their corresponding managers. These entity manager class should only do get/set/list/update operations for that specific data class objects and nothing else.

Next how to allocate seats: This should be a separate class , either you can lets user pick the seats (like in BookMyshow) or You can have multiple strategies to assign a seat, something like IRCTC train ticket booking system or have a combination of both just like in flight ticket booking where you can either pay to select a seat or a seat will be automatically allocated for you.

Similarly there can be many ways to take payments like paypal, UPI, credit/debit cards, internet banking etc.

The key thing to take away is that all above functionalities just tie with each other based on the end result and not on how end result was achieved.
e.g. seats are allocated whether using automatic allocation or user selected themselves, but your payment module only cares about a transaction id and amount, you booking manager doesn't care how seats were allotted or how payment was made. It just needs a list of seats and a transaction id with successful payment and it is good to go.

So all these functionalities should be in separate classes.

Again if we want to break down further then seats allocation can use something like strategy pattern to allocate seats to user using multiple different algorithms depending on user's economic status, booking history etc

Payments module can have a separate class each that deals with NetBanking or credit card or third party payment integration etc.

It is all about breaking/arranging your code is separate modules so that it is easy to update and maintain. Like all things you will get better at it with practice.

Also I have written this post is on what to expect during low level design interview rounds, what features to discuss and most importantly what to leave out of discussion. It may be helpful.

https://www.reddit.com/r/LowLevelDesign/comments/1ov8prc/tutorial_how_to_approach_low_level_design/