Use of Trigger on table which can have 100 hits / second. Will it hamper performance?
Unless you've badly coded it, then no. It is probably less then 10 writes per second. Even very write heavy databases are over 90% reads and under 10% writes.

Consider though that such things can be replaced by, say, an indexed view on this table that looks like the separate table. Or the DML can be done in a stored procedure so it's all in one place for clarity.

If you do hit issues, consider snapshot isolation so that the writes do not block reads.

Summary: should be OK, but there are things to mitigate if not.

Edit, read:write ratio

SELECT  SUM(ddius.user_updates) AS user_writes,
        SUM(ddius.user_lookups + ddius.user_scans + ddius.user_seeks) AS user_reads,
        OBJECT_NAME(ddius.object_id),
        1.0*SUM(ddius.user_lookups + ddius.user_scans + ddius.user_seeks)/NULLIF(SUM(ddius.user_updates), 0)
FROM    sys.dm_db_index_usage_stats AS ddius
GROUP BY OBJECT_NAME(ddius.object_id)
ORDER BY
 1.0*SUM(ddius.user_lookups + ddius.user_scans + ddius.user_seeks)/NULLIF(SUM(ddius.user_updates), 0)


Of 227 objects with indexes in my main OLTP system


only 24 have more writes then reads and about half are log or history tables.
101 have zero writes (mostly lookup or metadata tables)
Of the remainder, some of our heaviest use table have x2 or x10 or x25 and higher more reads than writes