City Scooter Share (CSS)

AI-Assisted Study Note

This page brings together public scenario links and AI-assisted research notes for study use. Start with the scenario brief, make your own attempt, and open the spoiler section only when you are ready to compare.

Scenario Snapshot

Field	Detail
Start here	Scenario brief PDF
Scenario source	Official or official-adjacent scenario
Current status	Official Practice (Live)
First public date	2017-04
Primary source	Open primary source
Coverage available	Scenario brief + Video or presentation + Discussion or analysis

Why This Scenario Matters

• This entry is included because it appears in the public CTA scenario corpus and has enough public evidence to track for study use.

Only Open If You Have Attempted the Scenario

The section below contains public follow-up links, board-call material, and AI-assisted notes compiled from those public sources.

Open follow-up links, Q&A, and analysis

Follow-Up Links

• Scenario brief PDF
• Mock board recording
• Analysis reference

Board Insights & Common Pitfalls

Generalized Judge Questions

• IoT Data Trap: “You have 2,000 scooters pinging GPS every 30 seconds. How will your ‘Rental History’ report perform in 3 years? Why not store pings as standard records?”
• Concurrency & Locking: “What happens if 500 riders try to unlock scooters at the exact same second during a festival? How do you prevent row locking on the Depot record?”
• Integration Resilience: “The Government License API is down during rider registration. Does the rider just stand there? Describe your fallback strategy.”
• Identity Bridge: “The scenario mentions an internal LDAP system. How does Salesforce connect to it? Explain the role of the Identity Provider (IdP) in your SAML flow.”
• Theft Detection: “How do you distinguish between a scooter being stolen and one being moved by a maintenance truck? Where does the logic reside (Salesforce vs. Middleware)?”

Common Mistakes

• GPS Object Bloat: Attempting to store every 30-second GPS update as a standard Custom Object record, leading to immediate storage limit exhaustion.
• Master-Detail for Rentals: Making “Rental” a detail of “Scooter,” which causes massive parent-record locking during high-frequency status updates.
• Synchronous License Checks: Using a synchronous callout for driver’s license verification, which hangs the mobile UI if the government service is slow.
• Vague QR Security: Proposing static QR code images instead of time-bound, encrypted JWTs rendered dynamically in the mobile app.

Strong Patterns

• Big Object Archiving: Using Big Objects for the massive volume of historical GPS pings and rentals while keeping the “Latest Status” field on the live Scooter record.
• IoT Buffer Layer: Using an external layer (AWS IoT or Heroku) to filter high-frequency pings and only pushing “Actionable Events” (like incidents) to Salesforce via Platform Events.
• Asynchronous Continuation: Leveraging the Continuation pattern for slow external pricing or license verification APIs to maintain a responsive mobile experience.

Strategic Insights

• The “High-Frequency” Test: CSS tests the architect’s ability to handle rapid-fire status updates and complex mobile concurrency.
• Standard-First Reporting: Success depends on justifying when to use standard reports vs. when CRM Analytics (Tableau CRM) is mandatory for high-volume telemetry.

Additional Notes

• Foundational official practice scenario focusing on IoT, high-volume transactions, and mobile-first B2C interactions.