Retrospective & The Road Ahead
Reflect on the design decisions that shaped BookVault, the trade-offs behind them, and where to go next across the wider Spring ecosystem and your career.
On this page
You've built BookVault from an empty project to a secured, tested, observable, containerized service. This final lesson steps back: why is it shaped the way it is, what did each decision trade off, and where do you go from here? Understanding the reasoning is what turns a finished project into transferable judgment.
The decisions that shaped BookVault
Every layer involved a choice. The valuable thing isn't the choice itself but knowing when it's right:
- A modular monolith, not microservices. BookVault is one deployable with clean internal boundaries. This traded away independent scaling and deployment for radical simplicity - the right trade until real pressure (team size, differing scale) justifies a split. The boundaries were drawn anyway, so a split stays cheap.
- Records for DTOs, classes for entities. Immutable value carriers versus managed, identity-bearing state - each tool matched to the job, rather than one style forced everywhere.
- Flyway over auto-DDL. Explicit, versioned, reviewable migrations traded a little upfront effort for a database whose shape is never a surprise.
- Blocking code with virtual threads, not reactive. BookVault kept simple, debuggable imperative code and got high concurrency from Java 21 - reserving reactive's complexity for problems that actually need it.
- Events over direct calls. A small amount of indirection bought decoupling and a ready seam for a future service split.
Judgment is knowing what NOT to build
Notice how much BookVault doesn't do: no premature microservices, no reactive rewrite, no native image by default. Senior engineering is largely restraint - reaching for complexity only when a real need justifies it. 'Start simple, add a layer when it earns its keep' is the through-line of the whole path, and the most valuable thing to carry forward.
Where BookVault would grow next
Real systems keep evolving. Honest next steps for BookVault:
- Split a service when one part needs independent scaling - the documented architecture shows how.
- Add caching (Spring Cache) for hot, read-heavy catalog queries.
- Richer domain: reservations, fines, due-date reminders (a scheduled job), search.
- Native image if you deploy serverless and cold-start matters.
- CI/CD: automate the test-build-deploy pipeline you now understand by hand.
The wider Spring ecosystem
The path covered the core, but Spring is vast. With your foundation, these are approachable:
- Spring Batch — robust large-scale batch processing.
- Spring Integration — enterprise integration patterns.
- Spring GraphQL — a GraphQL API alongside (or instead of) REST.
- Spring Authorization Server — run your own OAuth2/OIDC provider.
- Spring Cloud — the full distributed-systems toolkit you met in the microservices module.
- Spring AI — bring LLMs into your apps with the familiar model.
Each is 'more of the same Spring': starters, auto-configuration, injectable beans, portable abstractions. You already know how to learn them.
BookVault was a recipe, but along the way you learned techniques - dependency injection, transactions, the request lifecycle, the test pyramid, externalized config. Techniques transfer: a cook who understands heat and seasoning can make dishes they've never seen. You can now approach a Spring project you've never met and know how to reason about it - that's the real outcome, not the one app.
Keep building, and share it
The fastest way to deepen this is to build your own project end to end - your ideas, your domain - and put it on GitHub. Contribute to open source, write about what you learn, help someone a step behind. Teaching and building in public compound faster than any course.
Imagine a reviewer asks: 'Why didn't you build BookVault as microservices from the start, and why blocking code instead of reactive?' Give a clear, senior answer for each - the trade-off you made and the condition under which you'd choose differently.
What is the central engineering principle running through BookVault's design?
Key takeaways
- Each of BookVault's layers reflects a deliberate trade-off; the transferable skill is knowing when each choice is right.
- It favors a modular monolith, records vs classes by role, Flyway migrations, blocking code with virtual threads, and events over direct calls.
- Senior judgment is largely restraint: adopt complexity (a service split, reactive, native) only when a concrete need justifies it.
- BookVault would grow by splitting a service under real pressure, adding caching, a richer domain, native images, or CI/CD - each a deliberate next step.
- The wider Spring ecosystem (Batch, Integration, GraphQL, Authorization Server, Cloud, AI) is approachable because it's 'more of the same Spring'.
- You learned transferable techniques, not one recipe - keep building your own projects and sharing them.