Exam Professional Cloud Developer topic 1 question 271 discussion

https://cloud.google.com/pubsub/docs/samples/pubsub-publish-with-ordering-keys https://cloud.google.com/pubsub/docs/pull https://cloud.google.com/pubsub/docs/ordering

Ordering enabled: In this scenario, it's crucial that updates for the same stock symbol arrive in the correct order because the latest price update must reflect the actual current stock price. Enabling ordering ensures that messages with the same ordering key (e.g., stock symbol) are delivered in the order they were published. Pull subscription: This gives your application control over when and how messages are processed, which is often beneficial for managing concurrency and ensuring that updates are handled properly. Stock symbol as the ordering key: This ensures that updates for the same stock are processed in sequence, preventing issues where an older price update could overwrite a newer one.

I'll go with D, push subscription because of large amount of data, exactly once is not possible for push according to the documentation, and it's not important here to have exactly once. If rate is not changing, the event shouldn't be published anyway

I'll go with D, push subscription because of large amount of data, exactly once is not possible for push according to the documentation, and it's not important here to have exactly once. If rate is not changing, the event shouldn't be published anyway

iven the requirement that the downstream service needs the most up-to-date prices, you don't need to order the messages. In this case, a push subscription would be suitable as it delivers messages as they arrive, ensuring the downstream service receives the latest stock prices promptly. Exactly-once delivery can prevent the same message from being processed multiple times, which could be beneficial in this scenario.

I will go for A. B and C aren't good because you need to receive the prices in real time as they come. Between A and D: D with exactly-once delivery turned off you can process the same message many times and it isn't good for financial systems.

A is correct (I am not a contributor, so unable to vote). Rationale: 1. The downstream application needs only the most up-to-date value for a stock price. There's no need of historical values from a time series, so "ordering" does not make any sense in this scenario. This eliminates alternatives B, C and D. In addition, in alternative C, "using the stock symbol as the ordering key" has no practical effect, once "ordering" is not necessary. 2. About "push" and "pull": in a "push" subscription, whenever the topic is fed with a new value, it will keep pushing it to the application until an acknowledgement is received. Latency is lower in this case. In a "pull" subscription, there's an additional burden on the application to keep pulling from the topic. This increases latency. A "push" subscription is recommended in such scenarios.

Pull Subscription for Controlled Processing: A pull subscription gives you control over when and how messages are processed. This can be particularly important for maintaining the integrity of the in-memory database, as it allows for more deliberate handling of message backlogs and peak loads. Message Ordering Is Crucial: The ordering of stock price updates is critical. Using the stock symbol as the ordering key ensures that updates for a specific stock are processed in the order they were sent. This is vital to ensure the accuracy of stock price data, as prices must be updated in the sequence they were received to reflect the true market conditions. No Need for Exactly-Once Delivery: In most financial data scenarios, the latest data supersedes the old. If a message is delivered more than once, the last update for a given timestamp will leave the database in the correct state. Therefore, exactly-once delivery, which can add complexity and overhead, might not be necessary.