Как мы сократили объем данных в 10 раз, не повредив пользовательскому опыту, или переезд Postgres → ClickHouse

Это да, кафка это база особенно для таких log-oriented данных. Плюс надёжное хранение при сбоях. Но на кафку вряд ли будет апрув из-за ограниченности ресурсов, как людских, так и железных. Если вариантов не останется, будем пробивать кафку :)

Как мы сократили объем данных в 10 раз, не повредив пользовательскому опыту, или переезд Postgres → ClickHouse

Тоже была похожая проблема:
Одна команда внедряла фичу по генерации квартальных и полугодовых отчётов вещания плееров и увидели что фоновые джобы для крупных клиентов отлетали по таймауту в 1 час. Поняли что постгря не вывозит запрос для данных за квартал и тем более за полгода ("удивительно", не правда ли?).
Задачу на поиск решения делегировали в мою core команду. В итоге решили вытаскивать домен истории вещания из монолита в отдельный сервис.
Перекос нагрузки в сторону записи - ~3k записей в секунду. Чтение очень редкое - ~5 чтения в час. Решение нужно было довольно быстрое и с минимальными телодвижениями. Выбрали как раз "репликацию" из Postgres (партиционированный по дням) в ClikckHouse через PeerDB.

Итог:
На самых больших клиентах полный флоу генерации отчёта (запрос данных + постобработка + генерация xlsx/csv + сохранение в S3) выполняется ~3.5 минуты.
Нагрузочные тесты на хайлоад кластере показали что такой вариант имеет запас на рост ~x2.5 по нагрузке.
Сейчас этого хватает с головой и даёт время на выбор решения получше. Хотим уйти от Postgres + PeerDB + ClickHouse к ClickHouse + надёжный буфер, так как запись в ClickHouse хорошо работает с большими батчами в минимум 10к+ строк.

Python: Генераторы. Методы send, throw и close

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

Асинхронный SQLAlchemy 2: улучшение кода, методы обновления и удаления данных

Если говорить про постгрес, то в их документации сказано следующее:

Команда SET TRANSACTION устанавливает характеристики текущей транзакции. На последующие транзакции она не влияет.

https://postgrespro.ru/docs/postgrespro/15/sql-set-transaction

Как работают dict, slots и weakref в Python (и зачем это знать)

В главе "Объединяем slots, dict и weakref" сказано "Иногда хочется всего одновременно. Решение — объединить слоты с возможностью динамического добавления атрибутов, добавив в slots специальные поля dict и weakref.", но в коде этого нет.
Как я понимаю, ожидался такой код:

import weakref

class Resource:
    __slots__ = ('name', '__dict__', '__weakref__')
    
    def __init__(self, name):
        self.name = name

    def __repr__(self):
        return f"<Resource {self.name}>"

res = Resource("CacheResource")
weak_res = weakref.ref(res)
print("До удаления:", weak_res())
del res
print("После удаления:", weak_res())
# До удаления: <Resource CacheResource>
# После удаления: None

Верно?)

Go — 100 вопросов/заданий с собеседований

Так тут дело не в порядке переменных же)
swap меняет именно значения, которые были в переменных a и b.
Считаем что для тебя эта функция черный ящик.
Значит, передав туда переменные a=10 и b=15 и присвоив возвращаемое значение этой функции снова этим переменным, то ожидаем увидеть что в переменной a будет значение 15, а в переменной b - 10.