|
WorkOS AuthKit: Simplify Auth in Your Next.js App (Sponsored)
 |
Building auth in Next.js means managing redirects, handling tokens and sessions, and making sure it all works across routes—even in edge environments like Vercel.
WorkOS AuthKit solves this with a fully hosted login UI that supports SSO, MFA, passwordless auth, and password-based login. It handles redirects, token exchange, and session logic with minimal config.
Install the SDK, configure your redirect URI, and initialize the AuthKitProvider. AuthKit handles login and session logic from there.
This week’s system design refresher:
Trillions of Web Pages: Where Does Google Store Them? (Youtube video)
How Do Companies Ship Code to Production?
What is Event Sourcing?
How Data Lake Architecture Works
How Netflix Built a Distributed Counter
How TCP Handshake Works?
Early teams hiring engineers
SPONSOR US
Trillions of Web Pages: Where Does Google Store Them?
How Do Companies Ship Code to Production?
 |
Here are 11 steps from planning to production:
The Product Owner starts the entire process by creating user stories in a tool like Jira.
The Developer Team performs Sprint Planning activity and adds the user stories to the sprint.
Developers work on the assigned stories. Once a story is finished, they commit the code to Git and push it to GitHub.
Jenkins builds and runs the code through testing and quality check tools such as JUnit, Jacoco, and SonarQube.
If the build is successful, it is stored in the artifactory such as JFrog. Jenkins also deploys the build to the Dev Environment via Docker.
Next up, the feature gets deployed to the QA environment. Since multiple teams may be working on the same code base, multiple QA environments will be created
The QA team uses a particular QA environment and runs multiple test types such as QA, regression, and performance.
Once the QA verification is complete, features are deployed to the UAT (User Acceptance Testing) environment.
UAT testing verifies whether the feature satisfies the user’s requirements.
Once the UAT testing is successful, the builds become release candidates. They are deployed to the production environment based on a specific schedule.
The SRE team uses tools like ELK and Prometheus to monitor the production environment and handle alerts in case of issues.
Over to you: Will you add any other steps to the process?
What is Event Sourcing? How is it different from normal CRUD design?
The diagram below shows a comparison of normal CRUD system design and event sourcing system design. We use an order service as an example.
 |
The event sourcing paradigm is used to design a system with determinism. This changes the philosophy of normal system designs.
How does this work? Instead of recording the order states in the database, the event sourcing design persists the events that lead to the state changes in the event store. The event store is an append-only log. The events must be sequenced with incremental numbers to guarantee their ordering. The order states can be rebuilt from the events and maintained in OrderView. If the OrderView is down, we can always rely on the event store which is the source of truth to recover the order states.
Let's look at the detailed steps.
Non-Event Sourcing
Steps 1 and 2: Bob wants to buy a product. The order is created and inserted into the database.
Steps 3 and 4: Bob wants to change the quantity from 5 to 6. The order is modified with a new state.
Event Sourcing
Steps 1 and 2: Bob wants to buy a product. A NewOrderEvent is created, sequenced, and stored in the event store with eventID=321.
Steps 3 and 4: Bob wants to change the quantity from 5 to 6. A ModifyOrderEvent is created, sequenced, and persisted in the event store with eventID=322.
Step 5: The order view is rebuilt from the order events, showing the latest state of an order.
Over to you: Which type of system is suitable for event sourcing design? Have you used this paradigm in your work?