nerdexam
Google

PROFESSIONAL-DATA-ENGINEER · Question #37

Case Study 1 - Flowlogistic Company Overview Flowlogistic is a leading logistics and supply chain provider. They help businesses throughout the world manage their resources and transport them to their

The correct answer is B. Attach the timestamp and Package ID on the outbound message from each publisher device as they are sent to Clod Pub/Sub.. Option B is correct because for accurate historical analysis, timestamps must be captured at the source - the moment the tracking event actually occurs on the device - not at any downstream processing stage. Including the Package ID alongside the timestamp enables each event to b

Submitted by ahmad_uae· Mar 30, 2026Designing data processing systems

Question

Case Study 1 - Flowlogistic Company Overview Flowlogistic is a leading logistics and supply chain provider. They help businesses throughout the world manage their resources and transport them to their final managing and tracking orders and shipments has become a bottleneck. To improve operations, Flowlogistic developed proprietary technology for tracking shipments in real time at the parcel level. However, they are unable to deploy it because their technology stack, based on Apache Kafka, cannot support the processing volume. In addition, Flowlogistic wants to further analyze their orders and shipments to determine how best to deploy their resources. Solution Concept Flowlogistic wants to implement two concepts using the cloud: Use their proprietary technology in a real-time inventory-tracking system that indicates the location of their loads Perform analytics on all their orders and shipment logs, which contain both structured and unstructured data, to determine how best to deploy resources, which markets to expand info. They also want to use predictive analytics to learn earlier when a shipment will be delayed. Existing Technical Environment Flowlogistic architecture resides in a single data center: Databases 8 physical servers in 2 clusters - SQL Server - user data, inventory, static data 3 physical servers - Cassandra - metadata, tracking messages 10 Kafka servers - tracking message aggregation and batch insert Application servers - customer front end, middleware for order/customs 60 virtual machines across 20 physical servers - Tomcat - Java services - Nginx - static content - Batch servers Storage appliances - iSCSI for virtual machine (VM) hosts - Fibre Channel storage area network (FC SAN) - SQL server storage - Network-attached storage (NAS) image storage, logs, backups 10 Apache Hadoop /Spark servers - Core Data Lake - Data analysis workloads 20 miscellaneous servers - Jenkins, monitoring, bastion hosts, Business Requirements Build a reliable and reproducible environment with scaled panty of production. Aggregate data in a centralized Data Lake for analysis Use historical data to perform predictive analytics on future shipments Accurately track every shipment worldwide using proprietary technology Improve business agility and speed of innovation through rapid provisioning of new resources Analyze and optimize architecture for performance in the cloud Migrate fully to the cloud if all other requirements are met Technical Requirements Handle both streaming and batch data Migrate existing Hadoop workloads Ensure architecture is scalable and elastic to meet the changing demands of the company. Use managed services whenever possible Encrypt data flight and at rest Connect a VPN between the production data center and cloud environment SEO Statement We have grown so quickly that our inability to upgrade our infrastructure is really hampering further growth and efficiency. We are efficient at moving shipments around the world, but we are inefficient at moving data around. We need to organize our information so we can more easily understand where our customers are and what they are shipping. CTO Statement IT has never been a priority for us, so as our data has grown, we have not invested enough in our technology. I have a good staff to manage IT, but they are so busy managing our infrastructure that I cannot get them to do the things that really matter, such as organizing our data, building the analytics, and figuring out how to implement the CFO' s tracking technology. CFO Statement Part of our competitive advantage is that we penalize ourselves for late shipments and deliveries. Knowing where out shipments are at all times has a direct correlation to our bottom line and profitability. Additionally, I don't want to commit capital to building out a server environment. Flowlogistic is rolling out their real-time inventory tracking system. The tracking devices will all send package-tracking messages, which will now go to a single Google Cloud Pub/Sub topic instead of the Apache Kafka cluster. A subscriber application will then process the messages for real-time reporting and store them in Google BigQuery for historical analysis. You want to ensure the package data can be analyzed over time. Which approach should you take?

Options

  • AAttach the timestamp on each message in the Cloud Pub/Sub subscriber application as they are received.
  • BAttach the timestamp and Package ID on the outbound message from each publisher device as they are sent to Clod Pub/Sub.
  • CUse the NOW () function in BigQuery to record the event's time.
  • DUse the automatically generated timestamp from Cloud Pub/Sub to order the data.

How the community answered

(29 responses)
  • A
    3% (1)
  • B
    83% (24)
  • C
    10% (3)
  • D
    3% (1)

Explanation

Option B is correct because for accurate historical analysis, timestamps must be captured at the source - the moment the tracking event actually occurs on the device - not at any downstream processing stage. Including the Package ID alongside the timestamp enables each event to be uniquely identified and correlated across time in BigQuery.

Why the distractors fail:

  • A is wrong because subscriber-side timestamps reflect when the message arrived for processing, not when the tracking event happened; network latency and queue delays make this inaccurate for historical ordering.
  • C is wrong because NOW() in BigQuery captures the insert time, which is even further removed from the real-world event and introduces the most drift of all options.
  • D is wrong because Pub/Sub's auto-generated timestamp marks when the message reached Pub/Sub, not when the device recorded the scan - delays between device and cloud (connectivity gaps, batching) can skew this.

Memory tip: Think of it as the "closest to the source" rule - the further downstream you stamp an event, the more latency you bake in as artificial "data." In streaming pipelines, always trust event time (stamped at the producer) over processing time (stamped anywhere downstream).

Topics

#Real-time processing#Event time#Data ingestion#Google Cloud Pub/Sub

Community Discussion

No community discussion yet for this question.

Full PROFESSIONAL-DATA-ENGINEER Practice