Shmele

Для начала вам нужно проконсультироваться со своими финансистами/экономистами/бухгалтерами (кто занимается ценообразованием и отвечает за цены). Консультация нужна для того, чтобы выяснить, будет ли допустимым хранение только одной учетной цены в учетной валюте при условии, что все остальные цены (в других валютах) будут формироваться на лету путем пересчета учетной цены по курсу.
В ряде случаев это недопустимо, т.к. внезапно может выясниться, например, что ваши ценовики для формирования цен используют свои собственные представления о том, как именно нужно их формировать, и эти представления могут отличаться от логики вашего ПО (например, могут отличаться правила округления при пересчете по курсу, или не все полученные цифры удастся объяснить с точки зрения представлений программиста о математике и/или о здравом смысле).
Также может оказаться, что все цены в разных валютах фиксируются в бумажных документах (прейскурантах или т.п.) за подписью каких-либо должностных лиц, и эта фиксация происходит не ежедневно с учетом изменяющегося курса, а, к примеру, раз в месяц, или по факту изменения учетной цены. Если фиксация цен имеет место, то скорее всего цены на сайте всегда должны будут соответствовать ценам в документах, а не просто вычисляться по ежедневному курсу.
Дальнейшую стратегию нужно строить с учетом всплывших обстоятельств ценообразования. В идеале никаких нюансов не обнаружится и вы будете вольны реализовать работу с ценами по собственному усмотрению.

Когда речь идёт об обработке удалённых ресурсов критически важным становится стабильность и качество соединения, его производительность, а также производительность удалённых ресурсов. Если реализовать на Си максимально эффективный парсер сайта, который будет жевать его, допустим, за 1мс и точно такой же на каком-нибудь жирнющем пайтоне, у которого на обработку уйдёт, допустим, 15мс, очевидно эти числа ничто по сравнению со временем, которое будет затрачено на подключению и загрузку требуемого документа: 100мс на подключение, 1мб/10мбпс, итого 200мс только на то, чтобы получить документ, который может ещё с ошибками приехать или не не приехать вовсе, а удалённому серверу ещё и время потребуется, чтобы его обработать.

Итого важным становиться максимально асинхронная работа с загрузкой документа, а его обработка может занимать столько же, сколько идёт загрузка, ибо оная является узким горлом быстрее которого обработать не получится. Некоторым выходом может быть запуск параллельных процессов (потоков) на различные ресурсы, но злоупотреблять этим не стоит, так как ваш канал не резиновый и качество соединения может во много раз упасть, да и у системы есть серьёзные ограничения на количество одновременных соединений.

Литературу желательно на русском, так как с английским туго.

Начинайте учить язык, вы случайно решили войти в область где даже Русскоговорящие пишут статьи на английском.

на специальность информационная безопасность автоматизированных систем.

Очень размытое понятие, вам придётся определиться с областью в которую вы решили пойти, на все подобласти у вас жизни не хватит.

Сейчас стоит использовать только .on — все остальное будет потихоньку переходить в deprecated.
Отличие .bind от всех остальных в том, что он слушает события напрямую на элементе, тогда как все остальные подразумевают перехват и обработку всплывающих по DOM-дереву событий (т.н. «делегирование событий»).