Wan-Derer

гуглить "облачная онлайн касса" (потому что просто "онлайн касса" это физическое устройство ATM для приема платежей по карточкам налички)

Принимать ты можешь как угодно но онлайн касса быть должна.
Самозанятые могут не покупать онлайн кассу но должны формировать чек в приложении "Мой налог" для каждой продажи, там есть api, только вот получить его нормалтьтное описание можно лично с ними по общавщись или реверсить код, вот статья трехлетней давности

/\b\w+\b/gu
https://regex101.com/r/bJdmGa/2

Идете на сайт ICANN
Подаете заявку на новый TLD
Платите бабки, много бабок, очень много бабок. Зеленых, ессно.
Ведете переписку, очень много деловой переписки. На языке оригинала, ессно
Создаете необходимую инфраструктуру - Вы должны где-то хранить данные о зоне

ПРОФИТ! (Ну, может быть...)

ICANN периодически проводит рассмотрение заявок на регистрацию доменов верхнего уровня. Стоимость такого домена порядка $200000 плюс отчисления от продаж поддоменов. Кроме этого вы должны создать и поддерживать инфраструктуру для обслуживания домена.

Примерно так:

<T> void genericMethod(T argument) {
        // argument extends object
        System.out.println(argument);
    }

т.к. не понтяно какой тип будет у аргумента, он будет обладать только свойствами Object

<T extends SomeType> void someMethod(T argument) {
        System.out.println(argument);
    }

    abstract class SomeType implements SomeInterface {
    }

    interface SomeInterface {
        //TODO :: some methods
    }

Можно указать, что аргумент наследуют к.л. тип и тогдаможно вызывать методы этого типа.

В статически типизированных языках такие функции создавать не надо. Если вам понадобилось, то вы делаете что-то не так.

Если сумеешь внятно и с разумными доводами ответить - зачем тебе именно облачное решение, как бы ты это не понимал, то тогда пользуйся, иначе лучше:
* арендуй vps-ку с ценами от 3.5$ в год (лучше что то от 3$ в месяц, памяти будет по больше)
* установи туда любую открытую/бесплатную базу данных mysql/postgres/...
* установи локально открытый/бесплатный GUI для баз данных, например devart dba studio express (по уму тебе хватит любой GUI с поддержкой построителя запросов)
* установи локально условно бесплатный ms visual studio community (лучше не последнюю версию) и создавай приложения на win forms для своей базы данных на столько просто, что мне кажется для мелких проектов не превзойденно.
Благодаря майкрософтовской экосистеме работа с ее продуктами будет почти бесшовна (тут тебе и эксель, и доступ к старой ms access, и огромное комунити).
При должном старании кстати .net приложения будут кроссплатформенными, кросс-языковыми (вон даже на python.net можно писать) и достаточно шутрыми (экосистема уровня java, может даже круче).
p.s. веб бакэнд на visual studio писать грустно, точнее результат будет требовать windows server, это обходится но уже не просто а значит при выборе на чем писать здесь и сейчас быстро просто не подходит.

ключ 49 бит - log(66^8) - пусть для простоты 8байт, значение 32 байта (у тебя там hex строка)
только на значения тебе нужно 30 терабайта на каждый триллион - 32*10^12 и даже в идеальном случае еще 16тб на индекс ключа (чем больше оптимизируешь хранение тем больше операций на чтение и запись каждой)

Недавно была статья на хабре про тесты производительности работы mssql с похожими ключами миллионы записей

Я бы предложил схему с самописным индексом (мне кажется тут колхозить идеальнее всего).
* делишь ключ на 2 части (если бы ключ был не такой равномерный, то нужно было бы брать хеш от него), например по 4 байта
* младшие 4 байта (они наиболее равномерно будут распределены) - это номер блока в общем хранилище (на 1 триллион примерно 9кб, рекомендую. 16кб или 32кб, ssd на таких кластерах идеально работают), с массивом элементов: каждый из которых это вторые 4 байта ключа (старшие байты) + 32 байта искомое значение
для 16кб блока итоговое хранилище будет 70 тб - 2^32*16кб, можно прямо в дисковое устройство писать без файловой системы, по дискам пусть какой-нибудь рейд 0 раскидывает
* последняя запись в 16кб блоке - ссылка на дополнительное хранилище переполнений неравномерного распределения, его можно организовать как хочешь, на отдельном носителе

Итого на каждый запрос ты делаешь ровно одно чтение 16кб блока с диска, в полученном массиве ищешь нужный ключ и получаешь значение (если нет значит переполнения из-за неравномерного заполнения индекса, топать в дополнительное хранилище), кстати можно читать по секторно в процессе поиска, тогда если диск сумеет это оптимизировать будет 2х профит. Запись то точно так же - 1 чтение 16кб и запись 1 сектора диска, дозапись в массив. Кстати, если контролировать порядоковый номер ключевого значения (а что то мне говорит там будет простой перебор всех паролей) то будет последовательная запись блоков на диск, для hdd это идеальная ситуация. Иначе всю оперативную память используешь как самодельный lazy write буфер, при переполнении записываешь его на диск, отсортировав согласно дисковым устройствам и отсортировав порядок номеров секторов (тогда либо понимать как работает рейд либо самому раскидывать по дискам), операционные системы и контроллер диска это умеют но у них кеш маленький.

Такой хеш самый быстрый из всех возможных, так как запилен под задачу, оверхед хранения десяток другой терабайт. Кодить тут минимум, строк сотня другая, и то половина - это код сетевого сервиса, ты ведь захочешь разнести сервис хранения и логику по сети.

Добавь еще один уровень, будет 2 чтения по 8-16кб (когда ты не на 2 части делишь ключевое значение а на 3, первая часть ссылается на список ссылок на вторую часть, которые уже ссылаются на блоки с третьей частью), можно уменьшить этот оверхед но мне кажется скорость в твоей задаче важнее, ведь она упадет в два раза.
Универсальные базы данных делают многоуровневые древовидные индексы (это настраивается) и ради удобства и универсальности ты теряешь в скорости.

По Multithreading

"Что выведет следующий фрагмент кода"

Это - самый плохой класс задач на мультипоточку. Я видел много таких. Большинство из них основаны на Race Conditions и бывало и такое что негативный эффект не воспроизводится хотя и ожидается в задаче. А не воспроизводится по тесяче причин. По другой операционке или по другой версии JDK/JRE. Вобщем что
выведет код нужно выкинуть и заменить его на какой-то модульный тест да и еще и под нагрузкой. И беря
во внимание комплексность самого вопроса я-бы не стал такое выводить например в собеседования. Так
можно и мидла макнуть головой в сортир. Попробуйте распознать в коде например задачу обедающих
философов. Я готов спорить на коньяк что если вы никогда не слыхали - то не распознаете подвох.

Где и как подтянуть теорию Multithreading(М). Ответ - нигде. Самый лучший вариант - начать писать много кода
с мультипоточкой и наблюдать. Очень многие эффекты книги не объясняют. И 99% новичек нигде не прочитает
про разницу между использованием synchronized и atomic.

Вобщем берите код с нагрузкой и наблюдайте.

because "this.patientLastName" is null

Есть готовый api для диалогов

Alert alert = new Alert(AlertType.INFORMATION);
alert.setTitle("Имя окна");
alert.setHeaderText("хедер в окне:");
alert.setContentText("сообщение под хедером");
alert.showAndWait();

В джаве все необходимые библиотеки должны быть доступны в classpath. Classpath указывается при запуске java. В томкате, в конфиг файлах, тоже есть переменные, которые добавляются в classpath.
Вам нужно собрать самостоятельно все нужные библиотеки и скопировать их в любую из папок, которые указаны в classpath.
Насколько я помню, одна из них ~tomcat/lib; так же можно указать свою через конфиги.
Зависимости мавен умеет копировать сам: https://maven.apache.org/plugins/maven-dependency-...

Как-то так https://www.baeldung.com/java-taking-screenshots
А передавать, вариантов масса, например поднять web-сервер и туда постить изображения.