Ticket-like table and growing database
In general, this design will do the job without problems, specially that you only handle 400 rows per month, which is relatively small number. 

However, I have few recommendations to improve the design of the table:


price is better to be decimal, unless you want to store the price in "cents". i.e. if the ticket price is $5.99. you either have to store it as 599 and let the application process it when doing calculation, or viewing it; or, you store it in decimal(5,2) 
user field is better to be an integer, and the user ID in the users table is better to be an integer
Your primary key is good. Don't change it to ticket_id. 
Maybe a used flag field would be more clear to know which tickets are already used (This is personal preference)
Depending on the queries you run against this table you may create the required indexes.