Sql-server – the best solution to implement to replicate a database, with a purging process is in place

Does Transactional replication suit my problem the most among SQL Server replication mechanisms?

Out of all of the replication options - Transactional sounds like it is what helps you the most here. It gives the minimal latency and it doesn't need to be (but can be) bidirectional. You aren't merging changes and don't need Peer to Peer.

That said - Replication isn't "free" - you need to administer and monitor it and a poor setup could make performance problems worse. You should learn about the best options for performance and the best setup for performance and keep that in mind and keep your replication environment monitored.

Transactional replication is "easier" than Merge replication. But that doesn't mean you will always have a smooth sail and can always get away without someone with replication experience helping out.

If I have an opportunity to migrate from SQL Server 2008 to SQL Server 2012 would transactional replication have some breaking changes? I've read an article on technet that there might occur errors?

Unfortunately this is an "it depends" type of question. We could theoretically give you answers from our own experiences, but you will need to test. If you do bump into issues they will not necessarily be impossible issues that you cannot fix, they will require testing and tweaking.

Isn't SQL Server 2012 Always On mechanism better to solve my problem(I'm considering this option as last one, as I'm still using 2008 R2, and yet migration to 2012 is planned by not soon)?

In SQL Server 2012 AlwaysOn has something for you here that works potentially. Availability Groups are an answer here with the concept of an Active Secondary for reading purposes. But there are licensing concerns - you need to be in Enterprise on both the primary and the read only/active secondary. With the replication approach you still need to be licensed on both ends, but this is a good option for sure. It, too, has overhead associated and some administrative concerns that you should learn about - but it makes a great option.

I have implemented solution 2 multiple times in the past and it has proved extremely effective.

You are right in being concerned about the performance impact of replicating tables though. You will have to invest time in making sure replication isn't causing issues. Things to consider would be:

1. Where you will host the distributor - the DML and DDL performed on the replicated tables are passed from the publisher (where the original tables are) to the distributor. The actual commands are effectively copied into a set of special tables in a separate "distribution" database. The distributor has to be powerful enough to deal with this load. This could be the same instance as the publishing database, but with high volume OLTP or OLAP you may want to scale that out to another machine.

2. How often do you make schema changes to the tables you are wanting to replicate? Schema changes are possible, but they can be a nightmare in a replication topology. This will make schema changes something you will need to be much more careful with in future.

3. How much data is inserted/updated/deleted in the replicated tables? Replication can keep with with very high loads, but your underlying systems will need to be able to deal with that (it is very much a system architecture question). As replication is effectively copying the DML and DDL into a second database you can basically see it as creating double the data (and I/O etc.) compared to the same DB without replication.

There are many more things to consider, but this should give you a quick intro to what needs considering if you went with solution 2.