Quiet Chatter 1 : A Quiet Place to Talk About Books

Quiet Chatter is closed now. This series records what the service was and how it was built and run.

What It Is

Quiet Chatter (quiet-chatter.com) was a social network service built around sharing book recommendations. I planned it and built it alone, front end and back end.

Home screen: search and the recommended book talks.

A book's page: writing a book talk, and one written by another reader.

• 2025-11 MVP and beta test, submitted as my open mission in the Woowa Tech Course online pre-course
• 2026-01 Rebuilt for production, with the front end split out into React
• 2026-02 Official launch; Instagram promotion started
• 2026-04 Backend upgrade: from a monolith to microservices with an event-driven architecture

How It Started

During a gap in my career I joined the Woowa Tech Course online pre-course to keep my skills as a developer. Its last step was an open mission: define your own mission and submit it. I had run reading groups in the past, so I built an MVP of a service where people recommend books to each other.

I did not get into the main course. I kept developing the project anyway, launched it, and ran it until I closed it.

The Value It Offers

Reading is a private activity, and people prefer different fields, so it is hard to build deep common ground with others through it. Big portals and online bookstores do offer reviews and recommendations, but their algorithms lean toward advertising that sells books. Readers are exposed to marketing copy and rarely get a real exchange.

So there is a practical limit to connecting socially through reading, and with limited demand and a thin business model, it is not a problem a large platform will solve. I planned a service that keeps social connection going through reading while keeping people psychologically at ease.

• Social exchange through reading. People share a recommendation and their impression of a book they read, called a book talk, and respond to each other.
• Ease about posting in public. It is anonymous, and a post is hidden automatically after a while. That lowers the burden of writing.
• Low-stimulus, positive feedback. A post can receive a like (👍) or an "I feel the same" (❤️). I kept features that could have a negative effect to a minimum.

Promotion

For about a month I ran Instagram ads to bring in new users. Adult reading rates are higher among women than men, and I considered affinity for mobile communities, so I targeted women under 40 interested in books and publishing.

The ad reached about 10,000 people in total over the month. Average daily visitors stayed under 30.

The Instagram ad.

The ad summary after about a month and a half.

Tech Choices

Backend: Kotlin, Spring Boot 3, JPA, PostgreSQL, Redis, Redpanda.

• Kotlin. Java is what I know best. I chose Kotlin for its language-level support for functional style, null safety, and immutability, and to learn the thinking behind it. Many libraries are still tuned for Java, so compatibility stays a factor when I choose a language. I study with Java to Kotlin.
• JPA. JPA with QueryDSL was my standard stack at my previous job. Tools like Exposed remove framework magic and add speed and visibility, but JPA is still the widely adopted standard for ORM, with plenty of references. Weighing the cost of learning something new, I kept JPA at the center.
• PostgreSQL and Redis. PostgreSQL follows the ANSI SQL standard most strictly, supports JSONB, and can extend straight into vector storage for RAG, which will help when I add AI features. Redis is the cache: authentication is stateless with JWT, so the member lookup repeated on every request is cached.
• Hexagonal architecture. It limits how much a change in outside technology reaches the business logic. I studied it through Beomkyun Choi's book on domain-driven design and Toby Lee's Clean Spring course, and found it worth its cost in practice. I agree with the philosophy of Clean Architecture, but on a project that is already running I would keep the existing pattern and improve it with SOLID, because that is cheaper for a team. I can weigh that trade-off realistically.

Frontend: TypeScript, React 19 with Vite (CSR), Material UI, MSW.

• Why split the front end. The MVP rendered pages on the server with Thymeleaf. Real-time, reactive features were hard, and managing JavaScript inside the backend was uncomfortable.
• TypeScript. Explicit types make the code clearer to both a developer and an AI, and prevent some runtime problems. With so many references, it is also a language AI agents handle with few mistakes.
• React with Vite. React has the largest ecosystem and is close to a market standard. Next.js was an option, but I wanted the simplicity of pure client-side rendering.
• Material UI and MSW. MUI gives a natural responsive layout on mobile and desktop quickly. MSW mocks part of the API server so client tests do not depend on it. The client also generates TypeScript types from the server's OpenAPI document.

Why I Rebuilt It as Microservices

The business logic and traffic of Quiet Chatter fit a monolith easily. I know that. But many companies choose microservices with an event-driven architecture for where their traffic and service size are heading, and I wanted to use an architecture close to the current standard for real and grow by solving the problems it brings.

So I migrated the backend from one Spring Boot application on a single Lightsail instance to k3s, microservices, and events. Asynchronous events between services go through Redpanda (Kafka-compatible), and an API gateway is the single entry point for authentication and routing. The infrastructure is code in Terraform, from the VPC to EC2, the Auto Scaling Group, and RDS, so that going from zero to one is reproducible.

The code is split into one repository per part — infrastructure, front end, and each microservice — joined as Git submodules in a root repository (quietchatter-project).

Along the way I learned provisioning, cluster networking, node and pod management, domain design, and the outbox pattern for guaranteed message delivery.

Other Ecosystems

I am also interested in TypeScript full-stack and backend frameworks and in Python backend frameworks. TypeScript is direct and shares a language with the client; Python has an open ecosystem, is the first-class language of AI tooling, and has strong data libraries. Each language and technology has a history behind its strengths and weaknesses, and I would rather use each where it fits than insist on one.

LLMs and AI agents have made unfamiliar languages easier to learn. If work calls for a technology I do not know, I am ready to take it on.

The rest of this series: the infrastructure, five backend design cases, and how I develop it with AI agents.