These are the raw format notes that I took while studying for the Google Cloud Professional Cloud Developer Certification. I've linked to the various materials that I used to study in the Resources section at the bottom. I passed the test and am officially certified!
Benefits of microservice architecture compared to a monolithic application:
In order to achieve the promise of microservices, each service must be stateless. Being stateful causes availability issues if an instance of a service goes down and accessing a shared state is a bottleneck for scalability. Stateless service instances can start up quickly and shutdown gracefully.
retrylogic with exponential backoff
Objects are called
Entities are either root entities or have
Entities are composed of their
kind, id, and ancestor id
operations on one or more entities are called
transactions and are atomic
entities of the same kind do not need to have a consistent property set
3 types of queries:
keys-only when you only need the entity key
projection-query when you only need specific properties from the entity or properties included in the query filter
ancestor-query when you need strongly consistency
Datastore is excellent for structured data that is non-relational. It scales extremely well. However, unlike relational databases, it does not support
join operations. It does not support inequality filtering on multiple properties. It does not support filtering based on results of a subquery. Practically speaking, this means that you will often make two or more inequality queries and then compute the intersection.
Remember that Datastore stores keys lexographically. High read/write activity to a local neighborhood of keys (or a relatively new key) will result in bottlenecks. For numeric keys, you can use the allocateIds() method to get keys that are distributed for performance. Outside of that, avoid negative numbers, the number zero, and monotomically increasing numbers.
If you need higher read capacity of a portion of the key range, you can use replication.
Datastore transactions can fail when they run longer than 60 seconds, there are too many concurrent writes to the same entity group, or a transaction operates on more than 25 different entity groups. Datastore can return exceptions in cases where the transaction will eventually be committed succesfully - therefore, design your transactions to be idempotent. Idempotent means that a the final state will be the same even if a transaction is processed multiple times.
Be sure to measure and visualize The 4 Golden Metrics: