Robur

Но у сервисов все равно выходит что будет зависимость от этой библиотеки с шиной сообщений, и завязка на это апи. Правильно ли это все?

Ну так у вас задача именно так и сформулирована - "появилась необходимость завязать два сервиса друг с другом".
Вы не сможете завязать сервис на что-то внешнее если не добавите в него зависимость на это внешнее в том или ином виде.
В такой ситуации завязать на стандартное апи которое абстрагирует один сервис от другого - это хороший и даже правильный вариант.

Как проще реализовать подобные блоки?

Простыми div с заливкой и позиционированием, это ж просто черные и белые прямоугольники. Если хотите красоты в коде - то блоками before, after, тегов меньше, суть та же.

В первый рабочий день зайдите к шефу и скажите что хотите зарплату меньше. Добейтесь чтобы уменьшили до комфортной для вас суммы.

Потом поработайте с годик, каждый месяц выполняя данные упражнения:
- получая зарплату думайте "а могло бы быть X денег а не вот это вот".
- Общайтесь с коллегами, ненавязчиво выясняйте кто сколько получает, не показывайте удивление узнав что изначально вам и так предложили меньше чем в среднем в офисе.
- выяснив свой реальный уровень в этой конторе, и поняв что вы не хуже а местами и лучше людей которые получают заметно больше вас делая ту же самую работу, совместите первые два пункта. Прочувствуйте страдание и сожаление о том что вы при устройстве (сейчас) так глупо переживали о том что вас оценили выше чем вы того стоите.

через год, поднакопив это все, посчитайте сколько вы недополучили на своей "адекватной" зарплате относительно начального офера, и сколько вы не получили относительно того что компания реально могла бы вам платить за ваши знания, прочувствуйте что эта цена вашего симптома самозванца, затем идите к начальнику и говорите "я все понял, был неправ, хочу прибавку"

Это все конечно если вы из себя реально что-то представляете а не заскочили удачно обманув всех на интервью.

Это вы серезную проблему на самом деле затронули.
варианта два
- либо сделать блокировки на уровне БД, где над такой проблемой подумали бородатые дядьки и придумали разные решения (и вам нужна будет нормальная БД)
- либо поменять систему так чтобы такой проблемы вообще не было - обеспечить обработку только одного заказа в один момент времени, если у вас скрипт работает в единственном экземпляре, то вы можете приостановить обработку всех остальных заказов, если уже какой-то один обрабатывается. Например завести очередь, при поступлении заявки класть ее в эту очередь, брать и обрабатывать по одному от начала и до конца, и когда один заказ полностью завершился и сформирован, брать следующий, обрабатывать его.

городить какие-то свои блокировки поверх гугл-таблиц - гиблое дело, вы уменьшите вероятность, но не уберете ее полностью.

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

Если я свои проекты покажу на собесе, то будет плюсом или так же будут обращать внимание на отсутствие ВО ?

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

Разбейте стили так чтобы в одном файле были стили для одного компонента.
Включите css - модули, уберете 99% проблем.
дальше

import styles from './mybutton.module.scss'
...
<div className={styles.title}>
...

Общие стили вынесите в переменные и миксины.
стилизацию дочерних компонентов из родителя можно делать либо прокидыванием класса из пропсов,
либо путем добавления отдельных пропсов, например <button outlined/>
в общем виде второй путь предпочтителен, если у вас много где родитель навешивает явные стили на дочерние компоненты - то тут определенно что-то не так в структуре стилей.

styled-components для мобилок норм, для веба мне лично не нравятся, лишний код.