PractiseGrid.
Learn by building.
How SOFTTECHIT built a browser-based system design platform where developers draw architectures, test their decisions, and work through capacity and correctness challenges.
Make architecture
something you can try.
System design involves tradeoffs. The product needed to make those tradeoffs visible through actions and feedback.
Build. Evaluate. Adjust.
Developers place and connect components, configure capacity, and run a simulation against a challenge’s traffic, budget, latency, and correctness requirements. Feedback explains what constrained the design so the next change has a reason.
Start simply. Keep your work.
Guest play removes the need to create an account before trying a challenge. Signed-in users can save private designs, reopen them across devices, and track completions that the server independently verifies.
A visual workspace.
Clear rules underneath.
PractiseGrid brings together an architecture canvas, a guided tutorial, a challenge catalog, and account-backed progress. The canvas supports component connections, group selection and movement, undo, and trackpad pan and zoom. Developers can revisit a design as the workload and failure requirements change across rounds.
The catalog includes reservations, flash sales, short links, background jobs, and specialized workloads for CDNs, file storage, SQL read replicas, and search indexes. Each challenge states its assumptions and limitations. This is a deterministic teaching model, rather than a load test against deployed infrastructure.
The same evaluator runs in the browser for immediate feedback and on the server when a signed-in user submits a design. The server uses authoritative challenge rules instead of trusting a score supplied by the browser.
Details that make
the product work.
Interaction design, data ownership, and a consistent model shaped the implementation.
Keep the model technically honest.
Redis-style caching is an app-called dependency: the app connects to cache and SQL separately. Read replicas can offload eligible reads but do not add write capacity. Challenge feedback distinguishes capacity, atomic writes, background work, and failure requirements.
Preserve work through change.
PostgreSQL stores accounts, private saved designs, and verified completions. Revision checks detect conflicting updates, and ownership checks scope access to the signed-in user. Guest drafts and account drafts remain separate.
Modernize in useful stages.
The public pages use Next.js and React. The existing canvas remains a focused browser activity, served by the same application. Shared backend services and the evaluator were retained while the application gained a TypeScript and App Router foundation.
Make releases repeatable.
The deployment workflow tests and builds a packaged Node.js release before deployment. Database migrations run before activation, with a health check and application rollback path. Schema changes preserve compatibility with existing saved work.
A working platform.
Room to keep learning.
The implementation provides 15 system design problems and 45 rounds, with reusable JSON definitions for expanding the catalog. Developers can try the interactive sample, enter the lab as guests, or sign in to save designs and build verified progress.
Published workload notes explain the model’s assumptions, including balanced database partitions and illustrative latency and pricing. That context helps developers interpret a passing design and identify the production questions they would still need to investigate.
Try the learning flow on PractiseGrid. For a related project, explore our web application development services or our approach to website migration and modernization.