Designing a microservices architecture that has write and read services "sharing" a database

Suppose the following scenario: I have a ticket service for entertainment events. I will be storing information about events and available tickets in two different tables:

• One table, Events, has information about the event (name, type, location, etc) and the available tickets. For simplicity's sake, let's assume there's only one type of ticket.
• Another table, Tickets, that holds information about the tickets that were purchased: event, ticket number, customer data, etc.

For scalability issues (some times the purchasing of tickets holds much more traffic than the querying of ticket information), I'd like to split the write and read services of the Ticket table into different services.

Now, I've read in several places that each service should own its own database, meaning that the reading service shouldn't read from the write service's database and viceversa: the write service shouldn't write to the reading service's database.

What should be the best approach here, then?

1. Should I replicate the databases in each service, keeping them both updated with some sort automatic replication mechanism? In that case, both databases would have an Events and a Tickets table that would be synchronized with each other (say, every time the write service writes it sends a request/queues a message to update the read service's database).

2. Or should I forget about the splitting and just keep a single service for accessing these tables and scale them together? This could cause issues for people trying to order a ticket if I have too many connections to the DB simply querying it for information and viceversa.

Thank you.