може й так
якщо не лінь, можна коротко: що надають штатні засоби? В контексті тих питань що я вище описував. Ну там ... фейловер мабуть ручний, так? Що відбувається коли один з лідерів падає? Реплікація синхронна чи ні? Якщо лідер підняли, як резолвати діф і можливі конфлікти (якщо вони можуть бути, бо може якщо 1 лідер падає то весь запис припиняється)
цікаво просто, з якими проблемами стикаються і як вирішують їх в не-фейсбук масштабах, звичайних

ну для мене якщо говорять що мають — це готово до використання в продакшн без надбудови власних або 3rd party рішень. Ви мабуть маєте на увазі що мускул має передомови для розбивки по різним нодам. Просто ота вся інша частина, щоб довести це до робочого стану — досить значна

гадаю тут диявол в деталях, що саме вони «вміли». Що на рахунок алгоритму консенсусу, фейловера (ручний, автоматичний?), типу реплікації, конфліктів. Я щось сумніваюсь що Твіттер, Мета вибирали 3rd party рішення типу Vitness чи розробляли власні просто від скуки. Що саме забезпечує цей конфіг?

в цьому всьому є плюс — поки є такі штуки, у нас є робота, AI точно в цьому не розбереться. І завжди будуть адвокати/євангелісти які будуть приходити один за одним і перероблювати проект поки є гроші, а в нас буде робота і пікнік продовжуватиметься)

щось схоже у всіх своє DDD )

а що почитати порекомендуєте з цієї тематики? Еванса?

в доцільності моделювання предметної області я не сумніваюсь, просто конкретна подача «не мій шматок пирога». Мова ж не просто про доцільність моделі, а саме про DDD

ось наприклад те що мені нормально зайшло www.uber.com/...​icroservice-architecture

чим класна штука?

я суджу от чисто судячи з цієї статті — все занадто відірвано від практики, це все звучить як «оцей кінь — це отой сферичний кінь, а потім це група отаких сферичних коней, яка формує сферичне стадо» і все в такому дусі. Де тут привязка до практики взагалі?

про слабкі команди і тд. Так можна сказати що якщо ти не можеш попасти з рогатки в монету за 200 метрів, то проблема не рогатці а в тобі. Якщо щось вимагає занадто ідеальних сферичних умов, то це теж можна вважати недоліком. Хороша технологія повинна бути прагматичною, а не вимагати саду Едем і янголів

а чого не вистачає і в яких мовах програмування?

я декілька разів пробував читати DDD, не пішло. Я можу зрозуміти статтю Убера про розбивку мікросервіси на домени, бо там про конкретні і практичні речі: ось було дофіга, ось розбили і погрупували, закрили за гейтвеем і тд.
а тут все якось дуже абстрактно

дякую, хороша відповідь і діалог

та я не заперечую що масштабування реляційних бд це вельми складна штука і для цього потріба висококваліфікована команда db admins + devops

а які юзкейси можуть бути для цих NewSQL, які бізнес-сценарії, які дані і які патерни доступа? Я так сходу і не придумав де саме важливо мультирегіональна консистентність і транзакційність, тож ось що каже bing chat)

«Some of the use cases of Cloud Spanner are:

Financial Services: Cloud Spanner can be used to build financial trading systems that require low-latency transactions and high throughput
Gaming: Cloud Spanner can be used to build real-time multiplayer games that require low-latency transactions and high throughput
Retail: Cloud Spanner can be used to build e-commerce systems that require low-latency transactions and high throughput »

або замодулювати ті ж самі атрибути на рівні бази що не має пітримки acid з якимись trade-off і прийняти теж відповідні недоліки(наприклад, в конкурентному середовищі, що для досягнення того самого эффекту що і consistency + isolation транзакції треба буде полягатись на retry операції після спрацювання optimistic concurrency control, для досягнення atomicity треба модулювати схему данних специфічним чином і т.д..)

а я якось думав що досягнути acid поверх nosql не так просто. Наприклад як досягнути зміну даних в різних таблицях так щоб транзакційно, в nosql ? Ще ж Cassandra не підтримує джойни, так? Тобто треба або денормалізувати, або джойнити в памяті. Тобто паттерни доступа і те як храняться дані, вже накладають значні обмеження.
Наскільки я вас зрозумів, ви маєте на увазі мати версію в кожному рекорді, і повторювати операції якщо версія змінилася. Тобто якщо треба оновити order + shipment (суто штучний приклад, може їх можна оновлювати і окремо насправді), треба успішно пройти вставку з перевіркою версії для обох? В реляційних бд в разі часткового фейла транзакція відкатує всі ентіті, але ж тут транзакції не буде, тож можлива ситуація що десь апдейт зафейлився, а десь пройшов, і що тоді робити?
якщо ж рознести дані по різним сервісам і бд, то там теж складно досягти транзакційність (Saga pattern, або 2phase commit, і те і інше непросто)

так, можливо що історичні причини, як версія годиться, явних пояснень чому mysql я ніде не бачив
ну а що на рахунок Google Spanner? Мотив створення, за словами самих креаторів, те що їм не вистачало acid і доводилося городити транзакційність поверх nosql. Тож існують все ж таки випадки коли потрібні і класичні транзакції і multi-regional і multi-leader db ?

цю статтю я читав (раз я посилаюсь на неї), де там відповідь на питання «чому не nosql» ?

саме дискутувати не ризикну, проте цікаво почути думку)

є приклади масштабування реляційних бд — Meta недавно прикрутила Raft до mysql (легко нагуглите в meta engineering blog). Хоча на це пішло багато часу + не кожна компанія має такі можливості
але є певні штуки типу Citus, так? Стосовно NoSQL, якщо б це завжди підходило, то і Мета мабуть не морочилась би з mysql, тим паче що вони розробили cassandra, і гугл не створив би Spanner
є якісь причини чому вони так зробили, на вашу думку?

Підхід реплікації Master/Master корисний, коли вашій системі потрібно виконувати операції запису у великій кількості, адже цю функцію мають усі сервери бази даних.

маю сумнів що всі сервери баз даних мають цю функцію, так щоб просто і «from scratch». Можливо SQL Server має в Azure, ще AWS Aurora нібито має (заявлено так). Навіть у великих клауд провайдерів не у кожного є підтримка multi-leader, оскільки це передбачає значно більше ніж просто «розбив дані, оновив конфіг і все». Це ще передбачає надійний вибір лідера, фейловер, реплікацію з strong consistency, і резолюшн конфліктів. По-моєму, якщо б все було так просто, то навіщо Meta прикручувала до MySql мультилідер реплікацію роками.