Why I can store more than 8000 characters in varchar(max)?

SQL Server Varchar Max Length:

varchar [ ( n | max ) ] Variable-size string data. Use n to define the string size in bytes and can be a value from 1 through 8,000 or use max to indicate a column constraint size up to a maximum storage of 2^31-1 bytes (2 GB).

The max number for n is 8000 that you can specify for varchar. Reason being that the maximum length you can store in a row is 8 kB, and every character in varchar takes 1 byte. The max for nvarchar is nvarchar(4000) since that one takes 2 bytes per char.

Question 1: How does the 8000 characters come into play and where should I be aware of it? The answer to your first question 1 is...

Setting n to 8000 causes 8000 characters to come into play. You need to be aware of the Precision, Scale, and Length (Transact-SQL) references about char, nchar, nvarchar, and varchar. In contrast, setting n to max (no quotes) causes SQL Server to store (and return) the maximum number of bytes (as mentioned in your quote).

Question 2 : Will a .net datareader query to this column always return the full result with 100 000+ character? The answer to your 2nd Question is.

This is a .Net (not a SQL Server) question, but the .Net DataReader fetches a stream of bytes. A byte is not a character, and SQL Server returns bytes (not characters). If n is set to 8000 and the data type is nvarchar, SQL Server returns up to 8000 bytes, which the .Net datareader can interpret to be 4000 Unicode characters. If n is set to 8000 and the data type is varchar, SQL Server returns up to 8000 bytes, which the .Net datareader can interpret to be up to 8000 ANSI characters. If n is set to max and the data type is nvarchar, SQL Server returns up to 2^31-1 bytes, which the .Net datareader can interpret to be up to (2^31-1)/2 characters. If n is set to max and the data type is varchar, SQL Server returns up to 2^31-1 bytes, which the .Net datareader can interpret to be up to 2^31-1 ANSI characters.

If you choose use char or varchar (instead of nchar or nvarchar) because they can store more "characters" (more accurately: bytes), you need to be aware that many Unicode characters have no equivalent ANSI character (thus a large portion of our world's users will be unable to see their localized/native characters in your app).