Cross subscription follower ADX cluster - azure-data-explorer

Can an ADX cluster have a follower database pointing to another ADX cluster that resides in a different Azure subscription?

Yes the clusters can be in different subscriptions, the relevant related limitation is that the two clusters must be in the same region, see the
limitation section in the follower database docs.

Related

Best way to handle multiple container transactions operations in Cosmosdb Nosql?

Currently I am trying to design an application where we have a CosmosDB account representing a group of customers with:
One container is used an overall Metadata store that contains all customers
Other containers will containers will contain data specific to one customer where data will be partitioned on according to different categories of customer history etc.
When we onboard a new customer (which will not happen too often and once) we'd like to make sure that we create an row in the Overall customer Metadata and then provision the customer specific container if fail rollback the transaction if it fails. (In the future we'd like to remove customers as well.)
Unfortunately the Cosmosdb Nosql only supports transactions in one container within the same logical partition, and does not support multi-container transactions. Our own POC indicates the MongoDB api does support this but unfortunately MongoDB does not fit our use case as we need support for Azure Functions.
The heart of the problem here isn't whether Cosmos DB supports distributed transactions. The core problem is you can't enlist an Azure Control Plane action (in this case, creating a container resource) into a transaction.
Since you're building in the cloud, my recommendation would be to employ the outbox pattern to manage your provisioning state for your customers. There's an easy to understand example here you can read.
Given you are building a multi-tenant application for Cosmos DB and using containers as your tenant boundary, please note that the maximum number of databases and/or containers in an account is 500. Please see Service Quotas for more information.

How to track inactive and hot partitions in azure cosmos DB

I want to see the partitions where there is a lot of reads and writes
I also want to see the partitions where there's been no crud operations for long, so that I can clean it up
is that possible in cosmos db ?
Question: I want to know what are the partitions which are hot or inactive,
having to read or write on it
According to your further description,you want to know the distribute situations of requests cross your multiple partitions.
Actually,that metric could be touched in the Azure Portal Metrics Throughput tab.
You could determine the throughput distribution of any partitioned container broken down by partitions.More details,please refer to this document.

Firebase Scalability - More than 100k user at the same time and across multiple region

I know scalability is not an issue in Firebase and supports up to 100k Simultaneous connections(in general).
Based on pricing documentation:
You can create multiple database instances to go beyond the 100K
concurrent limit. See Pricing FAQ for more information.
Question 1: What if there is more than 200k users using simultaneously on the same database? The other half of the users could not query, connect or the request will be placed in queue?
(As a Firebase plan subscriber, I would like to know how Firebase deals with the problem to ensure the quality of the services provided to our customers are always in top-notch)
Since, App globalisation is common nowadays and many companies' practices are to have servers across multiple regions to provide better and stable performance. Online game for example which required low latency.
As for now, the firebase user is required to set the default location when creating the project which is non-editable afterward. Some issues even rises where the users realised they deployed their app to the wrong regions and do not have clues on how to change the regions.
This represents the country/region of your organisation/company. Your
selection also sets the appropriate currency for your revenue
reporting. The selected country does not determine the location of
your data for Firebase features. Google may process and store Customer
Data anywhere Google or its agents maintain facilities.
Question 2: Will or does Firebase provide a solution / tailor-made to such practice which having our database in multiple regions while having a headquartered region and multiple other regions sharing all the databases, functions and auth across the regions?
(For now to have multiple servers location, we have to create different projects and the user and data syncing will be a problem)
Hope the language does not offend, cheers!
It seems like your question (or at least your assumptions) is based on the Firebase Realtime Database, so I'll answer for that below.
Q1) You can create more than 2 databases in a single project, each of which allows 100K connections. So it can scale beyond 200K connections. All of these are hosted in the same region though, so you can't use each database for a separate region.
Q2) For a database solution that handles multiple regions, I'd recommend looking at Cloud Firestore. Also see: Cloud Firestore - selecting region to store data?

How to query secondary replicas in Azure Cosmos DB

As per this article, https://learn.microsoft.com/en-us/azure/cosmos-db/distribute-data-globally, each partition consists of four replicas for high availability.
Also, I understand that Stored procedures always run against the primary replica (where all writes go).
When we use DocumentClient to issue client side queries, there are options to set to query across specific regions. But I am not able to find how to query the secondary replicas.
How to query secondary replicas in Azure Cosmos DB
You may could get the answer from this document.
Azure Cosmos DB provides global distribution out of the box for availability and low latency reasons. You do not need to setup replicas etc. All writes are always durably quorum committed in a any region where you write while providing performance guarantees.

Can one single Corda node support multiple parties/accounts?

Just wonder if a single Corda node can support multiple accounts like Bitcoin does.
A related open question I found on discourse https://discourse.corda.net/t/can-you-have-a-corda-identity-adress-without-running-a-node/1298
From Peter FroystadFroystadP6d
Does Corda support multiple people having accounts/addresses on the network without running a Corda node?
Similar to how Bitcoin allow people to own coins with a private key, but not running a full node?
In the financial world, this would correspond to people having an account in the bank, and they would share facts on a 1-1 basis with their bank regarding their dealings. These customers wouldn't run a peer node however. But they would want a service similar to a Bitcoin wallet that would allow them to access their dealings with the bank
Corda is designed for varied institutions which are not all banks, so it doesn't have a direct concept of "account" like Bitcoin does. If you want to implement customer accounts on top of Corda you need to track the balances yourself and use Corda for inter-institutional transfers. Corda's ability to easily integrate with SQL databases and MQ makes that kind of integration quite easy though.
If you're asking about multiple identities on a single node, so one machine can do both legal entity A and B at once, the answer is: we're working on it.
It is now possible with Corda 4.3 and the new Accounts SDK
https://github.com/corda/accounts
However, it is not a simple drop in replacement for Party and requires changes to an existing cordapp and implementing several parts of the business logic of what you might consider an "account" or "wallet".
According to the blog post by Mike Hearn: https://discourse.corda.net/t/mobile-consumer-payment-experiences-with-corda-on-ledger-cash/966
Note that your balance in this scheme is simply your bank balance. There are no separate wallets.
It looks to me running multiple accounts/parties on a single node is not supported in the moment. Yet, we may expect the support realized in Phase 2 Bitcoin SPV wallet mode.
In phase two this is extended to support a model more like Bitcoin SPV, whereby the sending device manages its own private keys and transaction data. It thus becomes a true wallet app.

Resources