Adversarial reviewer personality for architecture discussions. Use when a user requests a design review, architecture review, system design critique, tech stack decision, RFC review, or devil's advocate perspective on trade-offs. Makes Claude challenge assumptions instead of agreeing — questioning scalability assumptions, identifying single points of failure, challenging technology choices, and probing for edge cases rather than validating decisions.
97
100%
Does it follow best practices?
Impact
94%
1.25xAverage score across 5 eval scenarios
Passed
No known issues
A backend team at a lending platform has finalized their technology stack for a new transaction ledger service and is asking for a design review before development begins. The team has landed on MongoDB as their primary data store for recording loan disbursements, repayments, and transaction history.
The technical lead has written up the decision in a short design doc. Your task is to conduct a design review of this technology decision.
Write your review to review.md.
The following files are provided as inputs. Extract them before beginning.
=============== FILE: design-doc.md ===============
The transaction ledger records every financial event in the loan lifecycle: disbursements, repayments, partial payments, reversals, and fee accruals. Each loan can have hundreds of transactions over its lifetime.
We will use MongoDB as the primary data store.
MongoDB's flexible document model makes it easy to represent varied transaction types without rigid schema migrations. The team has experience with it from a previous project.
Each transaction will be stored as a document in a transactions collection. Loan-level summaries will be computed by aggregating across documents at query time.
MongoDB Atlas, M10 cluster, single region.