|
Guide to Monitoring Modern Infrastructure (Sponsored)
 |
Build resilient systems, reduce downtime, and gain full-stack visibility at scale. This in-depth eBook shows you how to evolve your monitoring strategy for today’s dynamic, cloud-native environments with:
Key principles of effective observability in modern architectures
Techniques for tracking performance across ephemeral infrastructure
Real-world examples of metrics, logs, and traces working together"
This week’s system design refresher:
How Does SSO Work?
Best Practices in API Design
Key Terms in Domain-Driven Design
Top AI Agent Frameworks You Should Know
How OpenAI’s GPT-OSS 120B and 20B Models Work?
ByteByteGo Technical Interview Prep Kit
SPONSOR US
How Does SSO Work?
Single Sign-On (SSO) is an authentication scheme. It allows a user to log in to different systems using a single ID.
 |
Let’s walk through a typical SSO login flow:
Step 1: A user accesses a protected resource on an application like Gmail, which is a Service Provider (SP).
Step 2: The Gmail server detects that the user is not logged in and redirects the browser to the company’s Identity Provider (IdP) with an authentication request.
Step 3: The browser sends the user to the IdP.
Step 4: The IdP shows the login page where the user enters their login credentials.
Step 5: The IdP creates a secure token and returns it to the browser. The IdP also creates a session for future access. The browser forwards the token to Gmail.
Step 6: Gmail validates the token to ensure it comes from the IdP.
Step 7: Gmail returns the protected resource to the browser based on what the user is allowed to access.
This completes the basic SSO login flow. Let’s see what happens when the user navigates to another SSO-integrated application, like Slack.
Step 8-9: The user accesses Slack, and the Slack server detects that the user is not logged in. It redirects the browser to the IdP with a new authentication request.
Step 10: The browser sends the user back to the IdP.
Step 11-13: Since the user has already logged in with the IdP, it skips the login process and instead creates a new token for Slack. The new token is sent to the browser, which forwards it to Slack.
Step 14-15: Slack validates the token and grants the user access accordingly.
Over to you: Would you like to see an example flow for another application?
Best Practices in API Design
 |
APIs are the backbone of communication over the Internet. Well-designed APIs behave consistently, are predictable, and grow without friction. Some best practices to keep in mind are as follows:
Use Clear Naming: When building an API, choose straightforward and logical names. Be consistent and stick with intuitive URLs that denote collections.
Idempotency: APIs should be idempotent. They ensure safe retries by making repeated requests to produce the same result, especially for POST operations.
Pagination: APIs should support pagination to prevent performance bottlenecks and payload bloat. Some common pagination strategies are offset-based and cursor-based.
Sorting and Filtering: Query strings are an effective way to allow sorting and filtering of API responses. This makes it easy for developers to see what filters and sort orders are applied.
Cross Resource References: Use clear linking between connected resources. Avoid excessively long query strings that make the API harder to understand.
Rate Limiting: Rate limiting is used to control the number of requests a user can make to an API within a certain timeframe. This is crucial for maintaining the reliability and availability of the API.
Versioning: When modifying API endpoints, proper versioning to support backward compatibility is important.
Security: API security is mandatory for well-designed APIs. Use proper authentication and authorization with APIs using API Keys, JWTs, OAuth2, and other mechanisms.
Over to you: did we miss anything important?