Reading a Google-Style Design Document — Comprehension Exercises
Read the design document excerpt below, then answer comprehension questions about TL;DR purpose, non-goals, success criteria, and stakeholder identification in this format.
📄 PASSAGE — Read carefully before answering
Design Doc: Unified Rate Limiting Service (RLS-2026-Q2)
Authors: K. Vasylenko, P. Oduya | Reviewers: Platform, Security, Data | Status: In Review
TL;DR
We will build a centralised rate limiting service to replace per-service rate limiting logic duplicated across 14 microservices. This will reduce policy inconsistency, simplify auditing, and allow product teams to configure limits without a code deployment.
Goals
- Provide a single source of truth for all rate limit policies across OrbitShip services.
- Enable non-engineer stakeholders (product managers, trust & safety team) to update rate limit rules via a configuration UI without engineering involvement.
- Reduce time-to-change for rate limit policies from ~3 days (code change + review + deploy) to under 1 hour.
- Success criterion: 100% of production microservices are using RLS within 6 months of launch.
Non-Goals
- This design does not address DDoS mitigation at the network layer (handled by the CDN provider).
- We are not redesigning the authentication or session management systems.
- Improving rate limit logic for third-party integrations is a separate workstream.
Stakeholders
Platform team (owner), Product (consumer), Trust & Safety (policy author), Security (reviewer), Data (reporting consumer).
Question 1 of 4